From nobody Thu Jul 1 10:11:49 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 4B9553A0BC3; Thu, 1 Jul 2021 10:11:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, kaduk@mit.edu, lflynn@amsl.com X-Test-IDTracker: no X-IETF-IDTracker: 7.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162515950670.3713.226822910630663170@ietfa.amsl.com> Date: Thu, 01 Jul 2021 10:11:47 -0700 Archived-At: Subject: [IPsec] ipsecme - New Meeting Session Request for IETF 111 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: Thu, 01 Jul 2021 17:11:48 -0000 A new meeting session request has just been submitted by Liz Flynn, on behalf of the ipsecme working group. --------------------------------------------------------- Working Group Name: IP Security Maintenance and Extensions Area Name: Security Area Session Requester: Liz Flynn Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 30 Conflicts to Avoid: People who must be present: Yoav Nir Tero Kivinen Benjamin Kaduk Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Jul 2 15:05:38 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 559CB3A0A41; Fri, 2 Jul 2021 15:02:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: ipsec@ietf.org, kaduk@mit.edu X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162526337734.26814.1123439270082948604@ietfa.amsl.com> Date: Fri, 02 Jul 2021 15:02:57 -0700 Archived-At: Subject: [IPsec] ipsecme - Requested session has been scheduled for IETF 111 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2021 22:03:08 -0000 Dear Liz Flynn, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ipsecme Session 1 (1:00 requested) Monday, 26 July 2021, Session II 1430-1530 Room Name: Room 6 size: 506 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/111/sessions/ipsecme.ics Request Information: --------------------------------------------------------- Working Group Name: IP Security Maintenance and Extensions Area Name: Security Area Session Requester: Liz Flynn Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 30 Conflicts to Avoid: People who must be present: Benjamin Kaduk Tero Kivinen Yoav Nir Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Jul 3 08: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 8B61F3A1944 for ; Sat, 3 Jul 2021 08:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 pp8R22-Yb0pR for ; Sat, 3 Jul 2021 08:31:16 -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 3FFE53A1941 for ; Sat, 3 Jul 2021 08:31:16 -0700 (PDT) Received: from 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 163FV9e5002262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sat, 3 Jul 2021 11:31:13 -0400 Date: Sat, 3 Jul 2021 08:31:08 -0700 From: Benjamin Kaduk To: ipsec@ietf.org Message-ID: <20210703153108.GX17170@mit.edu> References: <315BBB8D-B55E-43C8-A988-ADC8780AD62E@gmail.com> <059201d76bf6$e29680c0$a7c38240$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <059201d76bf6$e29680c0$a7c38240$@gmail.com> 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, 03 Jul 2021 15:31:21 -0000 On Mon, Jun 28, 2021 at 11:23:32AM +0300, Valery Smyslov wrote: [...] > > - 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. I see that Paul has already agreed to move these references to Informative, but I just wanted to point out that it is possible to have a normative reference from a standards-track document to Informational/Experimental/etc. documents -- the "downreference" just needs to be called out during the IETF LC (and be subject to discussion at that time). There's even a "downref registry" (https://datatracker.ietf.org/doc/downref/) of documents that have been deemed to be suitable for referencing from standards-track RFCs and for which the IETF LC callout is not needed. This procedure is discussed in BCP 97. -Ben From nobody Mon Jul 5 00:46:52 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 67AB93A1E8B; Mon, 5 Jul 2021 00:46: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.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <162547119734.17721.13071426638048222061@ietfa.amsl.com> Date: Mon, 05 Jul 2021 00:46:37 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-iptfs-09.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, 05 Jul 2021 07:46:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : IP-TFS: Aggregation and Fragmentation Mode for ESP and its Use for IP Traffic Flow Security Author : Christian Hopps Filename : draft-ietf-ipsecme-iptfs-09.txt Pages : 30 Date : 2021-07-05 Abstract: This document describes a mechanism for aggregation and fragmentation of IP packets when they are being encapsulated in ESP payload. This new payload type can be used for various purposes such as decreasing encapsulation overhead for small IP packets; however, the focus in this document is to enhance IPsec traffic flow security (IP-TFS) by adding Traffic Flow Confidentiality (TFC) to encrypted IP encapsulated traffic. TFC is provided by obscuring the size and frequency of IP traffic using a fixed-sized, constant-send-rate IPsec tunnel. The solution allows for congestion control as well as non- constant send-rate usage. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-iptfs-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-iptfs-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 5 01:06: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 3506E3A0474 for ; Mon, 5 Jul 2021 01:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2YKr8SOm7pb for ; Mon, 5 Jul 2021 01:06:12 -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 C2E023A046E for ; Mon, 5 Jul 2021 01:06:11 -0700 (PDT) Received: from fraeml734-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GJHzj0Vyjz6J66c for ; Mon, 5 Jul 2021 15:55:29 +0800 (CST) Received: from kwepeml100004.china.huawei.com (7.221.188.19) by fraeml734-chm.china.huawei.com (10.206.15.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Mon, 5 Jul 2021 10:06:08 +0200 Received: from kwepeml500004.china.huawei.com (7.221.188.141) by kwepeml100004.china.huawei.com (7.221.188.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Mon, 5 Jul 2021 16:05:59 +0800 Received: from kwepeml500004.china.huawei.com ([7.221.188.141]) by kwepeml500004.china.huawei.com ([7.221.188.141]) with mapi id 15.01.2176.012; Mon, 5 Jul 2021 16:05:59 +0800 From: "Panwei (William)" To: "ipsec@ietf.org" Thread-Topic: I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.txt Thread-Index: AQHXcVWcdoeDBz6MZEq61ZUG3CA6GKs0BS1Q Date: Mon, 5 Jul 2021 08:05:59 +0000 Message-ID: <6b574666311b4885983df4b26b158953@huawei.com> References: <162545902175.31867.5147837556210174666@ietfa.amsl.com> In-Reply-To: <162545902175.31867.5147837556210174666@ietfa.amsl.com> 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] I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2021 08:06:16 -0000 Hi, According to the discussion on the mailing list, I update the draft to vers= ion 05. In this version, I deleted the unnecessary considerations for the c= onfiguration changes. For now, the solution is very simple and just include= s the negotiation at creating IKE SAs and optimization at rekeying IKE and = Child SAs. Comments and feedbacks are more than 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: Monday, July 5, 2021 12:24 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.tx= t >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > 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-05.txt > Pages : 9 > Date : 2021-07-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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-kampati-ipsecme-ikev2-sa-ts-payloa > ds-opt/ >=20 > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-kampati-ipsecme-ikev2-sa-ts-p > ayloads-opt-05 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-kampati-ipsecme-ikev2-sa-ts-pay= lo > ads-opt-05 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > 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 From nobody Mon Jul 5 01:07:26 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 D42D73A080E for ; Mon, 5 Jul 2021 01:07:18 -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 sewUcUE6szX7 for ; Mon, 5 Jul 2021 01:07:14 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6B83A0794 for ; Mon, 5 Jul 2021 01:07:13 -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 728A1803F3; Mon, 5 Jul 2021 08:07:12 +0000 (UTC) References: User-agent: mu4e 1.5.13; emacs 27.2 From: Christian Hopps To: Christian Hopps Cc: ipsec@ietf.org Date: Mon, 05 Jul 2021 03:48:49 -0400 In-reply-to: Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [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: Mon, 05 Jul 2021 08:07:25 -0000 --=-=-= Content-Type: text/plain; format=flowed Christian Hopps writes: > 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. I have published a new version clarifying that one does *not* need to set the reorder and replay windows to the smaller of the two values, and in the case of slow tunnels it very well may make sense to have a larger replay window for logging purposes and a small or zero reorder window. As this document achieved WGLC consensus over 3 months ago, I would request that the process please continue forward. Thanks, Chris. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAmDiva8ACgkQLh2DDte4 MCV2Lw//YnN4aoeXnI4EfTxut8EyT5HyAxWDSMoseqjxTcnzPu8zaNOqVFq8YrGB gpscIcQA6a3KA9qGB9ih0pfUlUGCVGRv4e3mEbtHQ6S+3ZDcFp728qia87dHWzGC uIcXp6807gi3hnti6MtcKI3M4YojhO0KnUqtmQtAC5G/ju0J43tzlIeGZWg7O97D pfyo4GUioG1FnRrjnvlT9vOWuQ5yCRPdyaoH/8o2WL7PkKB4rk2bEPTAIjPyaH64 eyXR4GF26ywKg65oPg6hi1kx3+9L+y7SshTmuv9haJAUbNtWO9KBj9dIKXtpbkNg p2EqWoSJ1KF+FM3BeR/3LWzcRxujFqB8oDBxN/0r64A/77SWx0vy5/xwJ5SUx46n oE9wDytmar/Ty8NSsIVnMtUpVyk1yw3qCERQA1u3Pw314mgXT8SWF8iJYk4g+pEP DOHG0h6vkKK+UUW2m3cdijVSp5tgCVFFmBrkXp8bi62TfmTLD3OEcQHq/HOaQi6q t1CJ6FD7Xw4XRVxVDoulsQt8aCXH5VsGq4ZzmBWo3VKLoCeyFNtJ/biiT7HCYUrD AbxePL6DmsXl4Py2JiiHszmfdcypuONQKyYJeXFjTVnoY85JYxCiCwspBAq+eyZb P9FfTXrgEOP3jzSegNBOYLsQAJh7uB3Ja2r3/f/9Wyn0660CVYQ= =ENE0 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 5 05:41:52 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 824F33A165A for ; Mon, 5 Jul 2021 05:41:51 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ynQUG4uWs5f for ; Mon, 5 Jul 2021 05:41:47 -0700 (PDT) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [IPv6:2a0b:5c81:1c1::37]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3FA43A1659 for ; Mon, 5 Jul 2021 05:41:46 -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 lahtoruutu.iki.fi (Postfix) with ESMTPSA id 317811B001B4 for ; Mon, 5 Jul 2021 15:41:43 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1625488903; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=ZpvJ4fAFAwvyUXKsxA5LAX8b3xNfatYDNMGQwpXIsp0=; b=HGsEOBEtM6N9CkQz1DQGAQVa5ZizK3r3FDCTPfSfO5+wlvofeSUCydKW7yZf5R6pXNkj2m tjZxs9CEVDSTM+Y7AVCEBQH1kiBMu/yxfcd5oXjAV0a8sSe4c43q7hu38LqWOpi1E3J9HW u7piLskSNOVbkkbuidJExlCo1KWTJVMkJryFeP5Iy0YpZ7Z6NJjt2LREYIbsmSffHrTkVF REC3Mx5MowfzeGKs/RNtGfTy04adRpSzu8dTDIPI3VtGLH/ubtjwwsvcyELHebEX0pzYci HrqTdiIPfW6/h+p5jiyR0rZghLQyalqmH+Vv8WAjoU1mKzwObNgkYFPmRXgh4g== Received: by fireball.acr.fi (Postfix, from userid 15204) id C18B125C12C3; Mon, 5 Jul 2021 15:41:42 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24802.65030.723818.414961@fireball.acr.fi> Date: Mon, 5 Jul 2021 15:41:42 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 4 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1625488903; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=ZpvJ4fAFAwvyUXKsxA5LAX8b3xNfatYDNMGQwpXIsp0=; b=bGnrvktu0phJTaGjuLrPewrn6OlWvd/t7vtAlev2NSizCv/wtCW9gJcZYOdc9zRFW/NNfj ThNudqFl50A28zbVUSa350Vxi7rrC+g9oasYfXrOhjTQ2jKkR+koWWI1UZK7oRWaQHyyDP 3mfq+C5uqO/vrIjlDShxMxxBZAuMGf3TyyXExmEdDvdXst7B6rOgOFPYX24DS8OH+5FHAJ f7tn4s8k1Lr/5NZnAP0plhZ2C+2dgqIuKzS24hPCLUHP2tR9Fmpfim7eQ+PaR+O6ChiF8s kD/4PM5ATLR24rVhigrjsWt+qAepnAgEDyGZnrlBHYwfEOgkWsL6r1zzUsN7hQ== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1625488903; a=rsa-sha256; cv=none; b=pixEYBHONgDojR0ovFIy+pZWNQ3qel9902JMgP7rQZGAXz7Wr5rXRJfZWD7E6gJ0s78vXW jMEZLbQfQcqOHy2GPdlyYEN+koZn08Opi2f7VPmA5aXh0jqtV0/YFp8R/XKZmckiNzWgq1 RKqbItnuopX9bJLWfGg6ZW1u70ys4+FmS2MoYahTubfz/6ouXl+3JhS/rkR4ANOZ/5E/oP T1Iyg170ha4iKJ5qmr+hVZ9fZgclj5G/5kHAWDP213XXpYgbx4XrS/Nje6m3wh6USvy4OF zjZbwIUNn8GRxGte/R3oj5zy7nLebRFq/DlUvV27GGD+g6eOzwUHPBojyWAX7w== Archived-At: Subject: [IPsec] IPsecME WG Agenda 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: Mon, 05 Jul 2021 12:41:52 -0000 As we now do have one hour meeting in the next IETF, I would like to ask people to send agenda requests to me as soon as possible. We only have one hour, so we might need to limit number of items on the agenda, so thats why I want to have list of agenda items early. So send your agenda requests to the ipsecme-chairs@ietf.org. The meeting will be on the Monday Session II (14:30-15:30 meeting time zone, 21:30-22:30 UTC), and will overlap with lamps, rats, wpack, irtfopen, anima, babel, pce, and tsvwg. -- kivinen@iki.fi From nobody Tue Jul 6 10:57:47 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 759BF3A2FCB; Tue, 6 Jul 2021 10:57:44 -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.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <162559426442.10809.16445048522779659661@ietfa.amsl.com> Date: Tue, 06 Jul 2021 10:57:44 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-multiple-ke-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2021 17:57:45 -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 : Multiple Key Exchanges in IKEv2 Authors : C. Tjhai M. Tomlinson G. Bartlett S. Fluhrer D. Van Geest O. Garcia-Morchon Valery Smyslov Filename : draft-ietf-ipsecme-ikev2-multiple-ke-03.txt Pages : 23 Date : 2021-07-06 Abstract: This document describes how to extend the Internet Key Exchange Protocol Version 2 (IKEv2) to allow multiple key exchanges to take place while computing a shared secret during a Security Association (SA) setup. The primary application of this feature in IKEv2 is the ability to perform one or more post-quantum key exchanges in conjunction with the classical (Elliptic Curve) Diffie-Hellman key exchange, so that the resulting shared key is resistant against quantum computer attacks. Another possible application is the ability to combine several key exchanges in situations when no single key exchange algorithm is trusted by both initiator and responder. This document updates RFC7296 by renaming a transform type 4 from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and renaming a field in the Key Exchange Payload from "Diffie-Hellman Group Num" to "Key Exchange Method". It also renames an IANA registry for this transform type from "Transform Type 4 - Diffie- Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange Method Transform IDs". These changes generalize key exchange algorithms that can be used in IKEv2. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-multiple-ke/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-multiple-ke-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-multiple-ke-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 6 23:16:18 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 A161F3A00E9 for ; Tue, 6 Jul 2021 23:16:16 -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 EHHhfk27DEV1 for ; Tue, 6 Jul 2021 23:16:12 -0700 (PDT) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 529C33A00E1 for ; Tue, 6 Jul 2021 23:16:12 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id t14-20020a05600c198eb029020c8aac53d4so8964042wmq.1 for ; Tue, 06 Jul 2021 23:16:12 -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=MCacVn8h7Px3LfOF6pfHKS28hiULhJk6c0vezBuOivc=; b=Jg7M9AT9syZ3HS/O7DPMlTPFzI0oe6TGz4USlJChiFclGAxHgAGGRl6tvl5A9O7Bzi VfAeQdDsRRlgB51OPMK3OipvpMTs2Kfcf2529yki2mKsVaw4jPETx19C7/6q6DJNJy4U MY/qvYoEb2LaIaDh/uDSOMfc5s9ndTAVT39X0aSQlS+ZZ/98Hki70C4RBQHIRiZEj/MQ 2XtMdCdTCTlgWJKS89Lm5iz1ZKAVDFKgYoW4VghtLON6WH0J9EGgIixpctr/b+2FFr7j Avbm/zz0QLYTkXGzcc00SZoYRk6xQhK5L8nmtFB9rV8ILM+bXAkL9PM8J0xdEqxpFPCW GLYA== 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=MCacVn8h7Px3LfOF6pfHKS28hiULhJk6c0vezBuOivc=; b=NonhMit/48PMqKq4R+O/4b6zGs/oq69/cXatprtINbOEfn5/UO4zpUJTMth/JT5jXQ JnjvzKFxAZ+IzM0bLdP97kIchrFNowxh6WVEHSYMldlBLrLtZoH1tY+SzawS2HjvPnaz M/CMvySWzwZPFgo/BXCQNonf7h4esBceJg+LgwRJwB9KpwCrTAXfvd5Lx6czwGU3cLdL UeOz5xw8HXCSdoUH2exMSA41Yg2Lv69h2PeWzVgqW0n6wGOwYVN1rXj1BOITPO8Dn2wI v1eLDuYtPGJb7dRkZ6AmSLQbVBjPq71UbSYeZf5Z5nqrZoTaB/enIkZ0h8qbG94Bv5mT ScOg== X-Gm-Message-State: AOAM531TF7Z5qy/1nmwcIApTBoBuZsXsYcF+bFZoshMyJRKHAbBudXaY kFzs+ve24kmLUH8ub7mK4J/PsXGK+E0= X-Google-Smtp-Source: ABdhPJxQrgYIw6oDn3Vv3DnBDqA//cgbkn7FhVns8c7UwQEIwGI0NXfbG1TQL66psU37BRPPqW62Rw== X-Received: by 2002:a05:600c:214b:: with SMTP id v11mr4809260wml.95.1625638569163; Tue, 06 Jul 2021 23:16:09 -0700 (PDT) Received: from buildpc ([93.188.44.204]) by smtp.gmail.com with ESMTPSA id f2sm18953247wrq.69.2021.07.06.23.16.08 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Jul 2021 23:16:08 -0700 (PDT) From: "Valery Smyslov" To: References: <162559426442.10809.16445048522779659661@ietfa.amsl.com> In-Reply-To: <162559426442.10809.16445048522779659661@ietfa.amsl.com> Date: Wed, 7 Jul 2021 09:16:09 +0300 Message-ID: <0ab001d772f7$946efff0$bd4cffd0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE3dNJBof4WH7BQBeY+DtMQlP28fqx3BLtw Content-Language: ru Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-multiple-ke-03.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, 07 Jul 2021 06:16:17 -0000 Hi, a new version of the draft contains few clarifications and minor editorial changes. We believe the draft is stable and ready for WGLC. Regards, Valery (for the authors). > 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 : Multiple Key Exchanges in IKEv2 > Authors : C. Tjhai > M. Tomlinson > G. Bartlett > S. Fluhrer > D. Van Geest > O. Garcia-Morchon > Valery Smyslov > Filename : draft-ietf-ipsecme-ikev2-multiple-ke-03.txt > Pages : 23 > Date : 2021-07-06 > > Abstract: > This document describes how to extend the Internet Key Exchange > Protocol Version 2 (IKEv2) to allow multiple key exchanges to take > place while computing a shared secret during a Security Association > (SA) setup. The primary application of this feature in IKEv2 is the > ability to perform one or more post-quantum key exchanges in > conjunction with the classical (Elliptic Curve) Diffie-Hellman key > exchange, so that the resulting shared key is resistant against > quantum computer attacks. Another possible application is the > ability to combine several key exchanges in situations when no single > key exchange algorithm is trusted by both initiator and responder. > > This document updates RFC7296 by renaming a transform type 4 from > "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and > renaming a field in the Key Exchange Payload from "Diffie-Hellman > Group Num" to "Key Exchange Method". It also renames an IANA > registry for this transform type from "Transform Type 4 - Diffie- > Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange > Method Transform IDs". These changes generalize key exchange > algorithms that can be used in IKEv2. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-multiple-ke/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-multiple-ke-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-multiple-ke-03 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Sun Jul 11 20:38: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 0B6C83A2BB4 for ; Sun, 11 Jul 2021 20:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=aiven.io 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 OspDsAQ114dB for ; Sun, 11 Jul 2021 20:38:36 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 CACEC3A2BB2 for ; Sun, 11 Jul 2021 20:38:35 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id h9so6380665ljm.5 for ; Sun, 11 Jul 2021 20:38:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aiven.io; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=mA3n2OBA28JRNB0YnYR+n/BzotVLDbtDLXmLMa2HTIo=; b=AHT08VKCRvwdzjbOdNZ6NC8I3Eka6Ks2h9LdZpPwQ21NedH7p27jiuoUaMNpeVOfC6 wGUfsK17cy+y3msEXHVc8n8qZ4rTQGG1vxCGmE5fpHXBxyQ7HW7JAJBV+TBK9HNHr1eR 7irUh8hYzDof59rh0uLolhhxF++2oKCS9utJo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=mA3n2OBA28JRNB0YnYR+n/BzotVLDbtDLXmLMa2HTIo=; b=g7dH+zwKjHXkmhrm0a89K/XcKiDsaszfR3ajyd3WiIANDx5bhlHquh7vfrO39LsrmC XKtK6x0/OZaUzJFZleHC1enozf/LAbXO9Exzr3HNheTGNr+Aa7p0vQAnBBnW1q4PZHd7 aIUYISnf4AFEqs3OK/KxsA5HlXO6CK1D+cvstlv2lJZHP8ngGLFlok6uVUKJBZ8xmF0k 4778afmJLArSfA2E75fVjmmGQx4DjZmhGqoDWCj1x/9N5Mn/g9HonaZ0POrts3Ndqgw9 WIG/39U82m4uhugBdFsEOCjLTYX88Zr++a3dNWvvY+q1V0H0HfeMFXOGjBm6VKU7UIyb GaYQ== X-Gm-Message-State: AOAM5319tPqIwg7GBY3mJE3n0vX64k+hGVcyi2xl53oPfeoKyyHQ08Gp 0HG/X8oEr2poBCvrVICnK7IWCUjc5o6wNgCDZzKeQeoP3SCkHA== X-Google-Smtp-Source: ABdhPJyYnAIpUVsfGAMkXSc6qTZRsTk/BC9C9dta3YTPMOBk4am+nEAr31+I5v11EQfpXm7IWoXCJFvnGGpRfoXOg3Y= X-Received: by 2002:a2e:5307:: with SMTP id h7mr3648678ljb.181.1626061112377; Sun, 11 Jul 2021 20:38:32 -0700 (PDT) MIME-Version: 1.0 References: <162545902175.31867.5147837556210174666@ietfa.amsl.com> <6b574666311b4885983df4b26b158953@huawei.com> <4e62fa1c-292-a14c-9ea9-2e9cad3e88f8@aiven.io> In-Reply-To: <4e62fa1c-292-a14c-9ea9-2e9cad3e88f8@aiven.io> From: Paul Wouters Date: Sun, 11 Jul 2021 23:38:21 -0400 Message-ID: To: ipsec@ietf.org Content-Type: multipart/mixed; boundary="000000000000fcb07505c6e4da6d" Archived-At: Subject: Re: [IPsec] I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 03:38:42 -0000 --000000000000fcb07505c6e4da6d Content-Type: multipart/alternative; boundary="000000000000fcb07205c6e4da6b" --000000000000fcb07205c6e4da6b Content-Type: text/plain; charset="UTF-8" Hmm, it used to be that if you are subscribed to one IETF list, you can post to any of them. That does not seem to work for the ipsec list :/ ---------- Forwarded message --------- From: Paul Wouters Date: Sun, Jul 11, 2021 at 11:34 PM Subject: Re: [IPsec] I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.txt To: Panwei (William) Cc: ipsec@ietf.org On Mon, 5 Jul 2021, Panwei (William) wrote: Hi Wei Pan, > According to the discussion on the mailing list, I update the draft to version 05. In this version, I deleted the unnecessary considerations for the configuration changes. For now, the solution is very simple and just includes the negotiation at creating IKE SAs and optimization at rekeying IKE and Child SAs. > > Comments and feedbacks are more than welcome. It is lookger much better and simpler, but I still had a few issues and wanted to make the document a bit shorter and clearer. I made some changes for your consideration. I've attached an updated xml and txt file in case you would like to use my changes. The changes are: - Reduced the text that was used to explain a lot of IKEv2 basics. Instead, a reference to IKEv2 should be enough. This greatly simplifies the text. - Remove the parts about "changed configuration". If the crypto parameters have changed, you SHOULD NOT use REKEY. RFC 7296 says this: In Section 2.8, "Note that, when rekeying, the new Child SA MAY have different Traffic Selectors and algorithms than the old one" was changed to "Note that, when rekeying, the new Child SA SHOULD NOT have different Traffic Selectors and algorithms than the old one". So if the configuration has changed, you should not do any kind of REKEY, whether it is OPTIMIZED or not. You should do a re-authentication (in other words, a new IKE from scratch) - IKE REKEY MUST contain KE, because RFC 7296 says: The main reason for rekeying the IKE SA is to ensure that the compromise of old keying material does not provide information about the current keys, or vice versa. Therefore, implementations MUST perform a new Diffie-Hellman exchange when rekeying the IKE SA. In other words, an initiator MUST NOT propose the value "NONE" for the Diffie-Hellman transform, and a responder MUST NOT accept such a proposal. This means that a successful exchange rekeying the IKE SA always includes the KEi/KEr payloads. - Removed: It also helps to avoid IP fragmentation of IKEv2 messages I don't think this is actually true, since on rekey there are no required CERT payloads, which is the vast majority of the payload size in IKE_AUTH that causes fragmentation. - Changed MINIMUM_REKEY{_SUPPORTED} to OPTIMIZED_REKEY{_SUPPORTED} This matches better with the OPTIMIZED_REKEY notify. Also, I find that "minimum" is a little confusing. It could mean "minimum lifetime" or "minimum of the previous one". I find "optimized" covers this better than "minium". - Shortened titles For improved readability of Table of Contents - Some grammar and style Open questions to the working group: 1) Should the SUPPORTED notify mean that peers MAY use this method or MUST use this method? There could be a use for making it MUST, as a peer could then eventually stop supporting the "old method". Initiators would know by the lack of the notify that they might not be able to rekey in the old way, and must add/delete or re-auth the SA. 2) Alternatively, the SUPPORTED notify could have a payload that signifies whether the old method is supported or not. 3) Should we look at supporting rekeying multiple Child SAs at once? Or should we tell people they should have used additional Traffic Selectors and combined the Child SAs into one ? 4) When a Child SA was negotiated with PFS, what should an optimized rekey do when there is no KE payload? Send INVALID_KE_PAYLOAD ? Paul > > 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: Monday, July 5, 2021 12:24 PM >> To: i-d-announce@ietf.org >> Subject: I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.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-05.txt >> Pages : 9 >> Date : 2021-07-04 >> >> 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 is also an htmlized version available at: >> https://datatracker.ietf.org/doc/html/draft-kampati-ipsecme-ikev2-sa-ts-p >> ayloads-opt-05 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-kampati-ipsecme-ikev2-sa-ts-paylo >> ads-opt-05 >> >> >> 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 > --000000000000fcb07205c6e4da6b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hmm, it used to be that if you are subscribed to one = IETF list, you can post to any of them. That does not seem to work for the = ipsec list :/


---------- Forwarded message ---------
= From: Paul Wouters <paul.wouters@aiven.i= o>
Date: Sun, Jul 11, 2021 at 11:34 PM
Subject: Re: [IP= sec] I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.txt
T= o: Panwei (William) <willia= m.panwei@huawei.com>
Cc: ipsec@= ietf.org <ipsec@ietf.org>


On Mon, 5 Jul 2021, Panwei (William) wrote:

Hi Wei Pan,

> According to the discussion on the mailing list, I update the draft to= version 05. In this version, I deleted the unnecessary considerations for = the configuration changes. For now, the solution is very simple and just in= cludes the negotiation at creating IKE SAs and optimization at rekeying IKE= and Child SAs.
>
> Comments and feedbacks are more than welcome.

It is lookger much better and simpler, but I still had a few issues and
wanted to make the document a bit shorter and clearer.=C2=A0 I made some changes for your consideration. I've attached an updated xml and txt fi= le
in case you would like to use my changes. The changes are:

- Reduced the text that was used to explain a lot of IKEv2 basics.

Instead, a reference to IKEv2 should be enough. This greatly simplifies
the text.

- Remove the parts about "changed configuration".

If the crypto parameters have changed, you SHOULD NOT use REKEY. RFC 7296 says this:

=C2=A0 =C2=A0 In Section 2.8, "Note that, when rekeying, the new Child= SA MAY have
=C2=A0 =C2=A0 different Traffic Selectors and algorithms than the old one&q= uot; was
=C2=A0 =C2=A0 changed to "Note that, when rekeying, the new Child SA S= HOULD NOT
=C2=A0 =C2=A0 have different Traffic Selectors and algorithms than the old = one".

So if the configuration has changed, you should not do any kind of REKEY, whether it is OPTIMIZED or not. You should do a re-authentication (in
other words, a new IKE from scratch)

- IKE REKEY MUST contain KE, because RFC 7296 says:

=C2=A0 =C2=A0 The main reason for rekeying the IKE SA is to ensure that the=
=C2=A0 =C2=A0 compromise of old keying material does not provide informatio= n about
=C2=A0 =C2=A0 the current keys, or vice versa.=C2=A0 Therefore, implementat= ions MUST
=C2=A0 =C2=A0 perform a new Diffie-Hellman exchange when rekeying the IKE S= A.=C2=A0 In
=C2=A0 =C2=A0 other words, an initiator MUST NOT propose the value "NO= NE" for the
=C2=A0 =C2=A0 Diffie-Hellman transform, and a responder MUST NOT accept suc= h a
=C2=A0 =C2=A0 proposal.=C2=A0 This means that a successful exchange rekeyin= g the IKE SA
=C2=A0 =C2=A0 always includes the KEi/KEr payloads.

- Removed: It also helps to avoid IP fragmentation of IKEv2 messages

I don't think this is actually true, since on rekey there are no requir= ed
CERT payloads, which is the vast majority of the payload size in IKE_AUTH that causes fragmentation.

- Changed MINIMUM_REKEY{_SUPPORTED} to OPTIMIZED_REKEY{_SUPPORTED}

This matches better with the OPTIMIZED_REKEY notify. Also, I find that
"minimum" is a little confusing. It could mean "minimum life= time" or
"minimum of the previous one". I find "optimized" cover= s this better
than "minium".

- Shortened titles

For improved readability of Table of Contents

- Some grammar and style

Open questions to the working group:

1) Should the SUPPORTED notify mean that peers MAY use this method or MUST<= br> =C2=A0 =C2=A0 use this method? There could be a use for making it MUST, as = a peer
=C2=A0 =C2=A0 could then eventually stop supporting the "old method&qu= ot;. Initiators
=C2=A0 =C2=A0 would know by the lack of the notify that they might not be a= ble to
=C2=A0 =C2=A0 rekey in the old way, and must add/delete or re-auth the SA.<= br>
2) Alternatively, the SUPPORTED notify could have a payload that signifies<= br> =C2=A0 =C2=A0 whether the old method is supported or not.

3) Should we look at supporting rekeying multiple Child SAs at once? Or
=C2=A0 =C2=A0 should we tell people they should have used additional Traffi= c
=C2=A0 =C2=A0 Selectors and combined the Child SAs into one ?

4) When a Child SA was negotiated with PFS, what should an optimized rekey<= br> =C2=A0 =C2=A0 do when there is no KE payload? Send INVALID_KE_PAYLOAD ?


Paul



>
> Regards & Thanks!
> Wei Pan
>
>> -----Original Message-----
>> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf >> Of i= nternet-drafts@ietf.org
>> Sent: Monday, July 5, 2021 12:24 PM
>> To: i-d= -announce@ietf.org
>> Subject: I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-op= t-05.txt
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts=
>> directories.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: IKEv2 Optional SA&TS Payloads in Child
>> Exchange
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Sandeep Kampati
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Wei Pan
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Meduri S S Bharath
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Meiling Chen
>>=C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 :
>> draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.txt
>>=C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= : 9
>>=C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = : 2021-07-04
>>
>> Abstract:
>>=C2=A0 =C2=A0 This document describes a method for reducing the siz= e of the
>>=C2=A0 =C2=A0 Internet Key Exchange version 2 (IKEv2) exchanges at = time of rekeying
>>=C2=A0 =C2=A0 IKE SAs and Child SAs by removing or making optional = of SA & TS
>>=C2=A0 =C2=A0 payloads.=C2=A0 Reducing size of IKEv2 exchanges is d= esirable for low
>>=C2=A0 =C2=A0 power consumption battery powered devices.=C2=A0 It a= lso helps to avoid IP
>>=C2=A0 =C2=A0 fragmentation of IKEv2 messages.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracke= r.ietf.org/doc/draft-kampati-ipsecme-ikev2-sa-ts-payloa
>> ds-opt/
>>
>> There is also an htmlized version available at:
>> https://datatracke= r.ietf.org/doc/html/draft-kampati-ipsecme-ikev2-sa-ts-p
>> ayloads-opt-05
>>
>> A diff from the previous version is available at:
>> https://www.ietf= .org/rfcdiff?url2=3Ddraft-kampati-ipsecme-ikev2-sa-ts-paylo
>> ads-opt-05
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Ann= ounce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d= -announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html<= /a> or
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org=
> https://www.ietf.org/mailman/listinfo/ipsec
>
--000000000000fcb07205c6e4da6b-- --000000000000fcb07505c6e4da6d Content-Type: text/plain; charset="US-ASCII"; name="draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05-pw.txt" Content-Disposition: attachment; filename="draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05-pw.txt" Content-Transfer-Encoding: base64 Content-ID: <17a98ca137d4593bcf31> X-Attachment-Id: 17a98ca137d4593bcf31 DQoNCg0KDQpJUFNFQ01FIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFMuIEthbXBhdGkNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFcuIFBhbg0KSW50ZW5kZWQgc3RhdHVz OiBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSHVhd2Vp DQpFeHBpcmVzOiAxMiBKYW51YXJ5IDIwMjIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIE0uIEJoYXJhdGgNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgTWF2ZW5pcg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNLiBDaGVuDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIENNQ0MNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDExIEp1bHkgMjAyMQ0KDQoNCiAgICAgICAgICAgIElLRXYyIE9wdGlv bmFsIFNBJlRTIFBheWxvYWRzIGluIENoaWxkIEV4Y2hhbmdlDQogICAgICAgICAgIGRyYWZ0LWth bXBhdGktaXBzZWNtZS1pa2V2Mi1zYS10cy1wYXlsb2Fkcy1vcHQtMDUNCg0KQWJzdHJhY3QNCg0K ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBtZXRob2QgZm9yIHJlZHVjaW5nIHRoZSBzaXpl IG9mIHRoZQ0KICAgSW50ZXJuZXQgS2V5IEV4Y2hhbmdlIHZlcnNpb24gMiAoSUtFdjIpIENSRUFU RV9DSElMRF9TQSBleGNoYW5nZXMNCiAgIHVzZWQgZm9yIHJla2V5aW5nIG9mIHRoZSBJS0Ugb3Ig Q2hpbGQgU0EgYnkgcmVwbGFjaW5nIHRoZSBTQSBhbmQgVFMNCiAgIHBheWxvYWRzIHdpdGggYSBO b3RpZnkgTWVzc2FnZSBwYXlsb2FkLiAgUmVkdWNpbmcgc2l6ZSBhbmQgY29tcGxleGl0eQ0KICAg b2YgSUtFdjIgZXhjaGFuZ2VzIGlzIGVzcGVjaWFsbHkgdXNlZnVsIGZvciBsb3cgcG93ZXIgY29u c3VtcHRpb24NCiAgIGJhdHRlcnkgcG93ZXJlZCBkZXZpY2VzLg0KDQpTdGF0dXMgb2YgVGhpcyBN ZW1vDQoNCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9y bWFuY2Ugd2l0aCB0aGUNCiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuDQoNCiAg IEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVu Z2luZWVyaW5nDQogICBUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMg bWF5IGFsc28gZGlzdHJpYnV0ZQ0KICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJh ZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC0NCiAgIERyYWZ0cyBpcyBhdCBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly4NCg0KICAgSW50ZXJuZXQt RHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9u dGhzDQogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3Ro ZXIgZG9jdW1lbnRzIGF0IGFueQ0KICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNl IEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UNCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhl bSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiINCg0KICAgVGhpcyBJbnRlcm5ldC1E cmFmdCB3aWxsIGV4cGlyZSBvbiAxMiBKYW51YXJ5IDIwMjIuDQoNCkNvcHlyaWdodCBOb3RpY2UN Cg0KICAgQ29weXJpZ2h0IChjKSAyMDIxIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50 aWZpZWQgYXMgdGhlDQogICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4N Cg0KICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1 c3QncyBMZWdhbA0KICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cyAoaHR0 cHM6Ly90cnVzdGVlLmlldGYub3JnLw0KICAgbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhl IGRhdGUgb2YgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4NCiAgIFBsZWFzZSByZXZpZXcg dGhlc2UgZG9jdW1lbnRzIGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cw0K DQoNCg0KS2FtcGF0aSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgMTIgSmFudWFyeSAyMDIyICAg ICAgICAgICAgICAgIFtQYWdlIDFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgSUtFdjIgT3B0aW9u YWwgQ2hpbGQgU0EmVFMgUGF5bG9hZHMgICAgICAgICBKdWx5IDIwMjENCg0KDQogICBhbmQgcmVz dHJpY3Rpb25zIHdpdGggcmVzcGVjdCB0byB0aGlzIGRvY3VtZW50LiAgQ29kZSBDb21wb25lbnRz DQogICBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QgaW5jbHVkZSBTaW1wbGlmaWVk IEJTRCBMaWNlbnNlIHRleHQNCiAgIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZiB0aGUg VHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlDQogICBwcm92aWRlZCB3aXRob3V0IHdhcnJh bnR5IGFzIGRlc2NyaWJlZCBpbiB0aGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZS4NCg0KVGFibGUg b2YgQ29udGVudHMNCg0KICAgMS4gIEludHJvZHVjdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAyDQogICAyLiAgQ29udmVudGlvbnMgVXNlZCBp biBUaGlzIERvY3VtZW50IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDMNCiAgICAgMi4x LiAgUmVxdWlyZW1lbnRzIExhbmd1YWdlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAgMw0KICAgMy4gIE5lZ290aWF0aW9uIG9mIFN1cHBvcnQgZm9yIE9QVElNSVpFRCBSRUtF WSAgLiAuIC4gLiAuIC4gLiAuIC4gICAzDQogICA0LiAgT3B0aW1pemVkIFJla2V5IG9mIHRoZSBJ S0UgU0EgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQNCiAgIDUuICBPcHRpbWl6 ZWQgUmVrZXkgb2YgQ2hpbGQgU0FzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAg NQ0KICAgNi4gIFBheWxvYWQgRm9ybWF0cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gICA1DQogICAgIDYuMS4gIE9QVElNSVpFRF9SRUtFWV9TVVBQT1JURUQg Tm90aWZ5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUNCiAgICAgNi4yLiAgT1BUSU1JWkVE X1JFS0VZIE5vdGlmeSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNg0KICAg Ny4gIElBTkEgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gICA2DQogICA4LiAgT3BlcmF0aW9uYWwgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDcNCiAgIDkuICBTZWN1cml0eSBDb25zaWRlcmF0 aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNw0KICAgMTAuIEFj a25vd2xlZGdtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gICA3DQogICAxMS4gTm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgIDcNCiAgIEF1dGhvcnMnIEFkZHJlc3NlcyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNw0KDQoxLiAgSW50cm9kdWN0 aW9uDQoNCiAgIFRoZSBJbnRlcm5ldCBLZXkgRXhjaGFuZ2UgcHJvdG9jb2wgdmVyc2lvbiAyIChJ S0V2MikgW1JGQzcyOTZdIGlzDQogICB1c2VkIHRvIG5lZ290aWF0ZSBTZWN1cml0eSBBc3NvY2lh dGlvbiAoU0EpIHBhcmFtZXRlcnMgZm9yIHRoZSBJS0UgU0ENCiAgIGFuZCB0aGUgQ2hpbGQgU0Fz LiAgQ3J5cHRvZ3JhcGhpYyBrZXkgbWF0ZXJpYWwgZm9yIHRoZXNlIFNBcyBoYXZlIGENCiAgIGxp bWl0ZWQgbGlmZXRpbWUgYmVmb3JlIGl0IG5lZWRzIHRvIGJlIHJlZnJlc2hlcywgYSBwcm9jZXNz IHJlZmVycmVkDQogICB0byBhcyAicmVrZXlpbmciLiAgSUtFdjIgdXNlcyB0aGUgQ1JFQVRFX0NI SUxEX1NBIGV4Y2hhbmdlIHRvIHJla2V5DQogICBlaXRoZXIgdGhlIElLRSBTQSBvciB0aGUgQ2hp bGQgU0FzLg0KDQogICBXaGVuIHJla2V5aW5nLCBhIGZ1bGwgc2V0IG9mIHByZXZpb3VzbHkgbmVn b3RpYXRlZCBwYXJhbWV0ZXJzIGFyZQ0KICAgZXhjaGFuZ2VkLiAgSG93ZXZlciwgbW9zdCBvZiB0 aGVzZSBwYXJhbWV0ZXJzIHdpbGwgYmUgdGhlIHNhbWUsIGFuZA0KICAgc29tZSBvZiB0aGVzZSBw YXJhbWV0ZXJzIE1VU1QgYmUgdGhlIHNhbWUuDQoNCiAgIEZvciBleGFtcGxlLCB0aGUgVHJhZmZp YyBTZWxlY3RvciAoVFMpIG5lZ290aWF0ZWQgZm9yIHRoZSBuZXcgQ2hpbGQNCiAgIFNBIE1VU1Qg Y292ZXIgdGhlIFRyYWZmaWMgU2VsZWN0b3JzIG5lZ290aWF0ZWQgZm9yIHRoZSBvbGQgQ2hpbGQg U0EuDQogICBBbmQgaW4gcHJhY3RpY2FsbHkgYWxsIGNhc2VzLCBhIG5ldyBDaGlsZCBTQSB3b3Vs ZCBub3QgbmVlZCB0byBjb3Zlcg0KICAgbW9yZSBUcmFmZmljIFNlbGVjdG9ycy4gIEluIHRoZSBy YXJlIGNhc2Ugd2hlcmUgdGhpcyB3b3VsZCBiZSBuZWVkZWQsDQogICBhIG5ldyBDaGlsZCBTQSBj b3VsZCBiZSBuZWdvdGlhdGllZCBpbnN0ZWFkIG9mIHRoZSBjdXJyZW50IENoaWxkIFNBDQogICBi ZWluZyByZWtleWVkLiAgU2ltaWxhcmx5LCBJS0V2MiBzdGF0ZXMgdGhhdCB0aGUgY3J5cHRvZ3Jh cGhpYw0KICAgcGFyYW1ldGVycyBuZWdvdGlhdGVkIGZvciByZWtleWluZyBTSE9VTEQgTk9UIGJl IGRpZmZlcmVudC4gIFRoaXMNCiAgIG1lYW5zIHRoYXQgdGhlIHNlY3VyaXR5IHByb3BlcnRpZXMg b2YgdGhlIElLRSBvciBDaGlsZCBTQSBpbiBwcmFjdGlzZQ0KICAgZG8gbm90IGNoYW5nZSBkdXJp bmcgYSB0eXBpY2FsIHJla2V5Lg0KDQoNCg0KDQoNCg0KS2FtcGF0aSwgZXQgYWwuICAgICAgICAg IEV4cGlyZXMgMTIgSmFudWFyeSAyMDIyICAgICAgICAgICAgICAgIFtQYWdlIDJdDQoMDQpJbnRl cm5ldC1EcmFmdCAgICAgSUtFdjIgT3B0aW9uYWwgQ2hpbGQgU0EmVFMgUGF5bG9hZHMgICAgICAg ICBKdWx5IDIwMjENCg0KDQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBhIG1ldGhvZCB0byBv bWl0IHRoZXNlIHBhcmFtZXRlcnMgYW5kIHJlcGxhY2UNCiAgIHRoZW0gd2l0aCBhIHNpbmdsZSBO b3RpZnkgTWVzc2FnZSBkZWNsYXJpbmcgdGhhdCBhbGwgdGhlc2UgcGFyYW1ldGVycw0KICAgYXJl IGlkZW50aWNhbCB0byB0aGUgb3JpZ2luYWxseSBuZWdvdGlhdGVkIHBhcmFtZXRlcnMuDQoNCiAg IEZvciBzZWN1cml0eSBnYXRld2F5cy9lUERHIGluIDRHIG5ldHdvcmtzIG9yIGNSQU4vQ2xvdWQg Z2F0ZXdheXMgaW4NCiAgIDVHIG5ldHdvcmtzLCBnYXRld2F5cyB0eXBpY2FsbHkgc3VwcG9ydCBt b3JlIHRoYW4gMTAwLDAwMCBJS0UvSVBTRUMNCiAgIHR1bm5lbHMuICBBdCBhbnkgcG9pbnQgaW4g dGltZSwgdGhlcmUgd2lsbCBiZSBodW5kcmVkcyBvciB0aG91c2FuZHMNCiAgIG9mIElLRSBTQXMg YW5kIENoaWxkIFNBcyB0aGF0IGFyZSBiZWluZyByZWtleWVkLiAgVGhpcyB0YWtlcyBhIGxhcmdl DQogICBhbW91bnQgb2YgYmFuZHdpZHRoIGFuZCBDUFUgcG93ZXIgYW5kIGFueSBwcm90b2NvbCBz aW1wbGlmaWNhdGlvbiBvcg0KICAgYmFuZHdpZHRoIHJlZHVjaW5nIHdvdWxkIHJlc3VsdCBpbiBh biBzaWduaWZpY2FudCByZXNvdXJjZSBzYXZpbmcuDQoNCiAgIEZvciBJbnRlcm5ldCBvZiBUaGlu Z3MgKElvVCkgZGV2aWNlcyB3aGljaCB1dGlsaXplIGxvdyBwb3dlcg0KICAgY29uc3VtcHRpb24g dGVjaG5vbG9neSwgcmVkdWNpbmcgdGhlIHNpemUgb2YgcmVrZXkgZXhjaGFuZ2UgcmVkdWNlcw0K ICAgaXRzIHBvd2VyIGNvbnN1bXB0aW9uLCBhcyBzZW5kaW5nIGJ5dGVzIG92ZXIgdGhlIGFpciBp cyB1c3VhbGx5IHRoZQ0KICAgbW9zdCBwb3dlciBjb25zdW1pbmcgb3BlcmF0aW9uIG9mIHN1Y2gg YSBkZXZpY2UuICBSZWR1Y2luZyB0aGUgQ1BVDQogICBvcGVyYXRpb25zIHJlcXVpcmVkIHRvIHZl cmlmeSB0aGUgcmVrZXkgZXhjaGFuZ2VzIHBhcmFtZXRlcnMgd2lsbA0KICAgYWxzbyBzYXZlIHBv d2VyIGFuZCBleHRlbmQgdGhlIGxpZmV0aW1lIGZvciB0aGVzZSBkZXZpY2VzLg0KDQogICBXaGVu IHVzaW5nIGlkZW50aWNhbCBwYXJhbWV0ZXJzIGR1cmluZyB0aGUgSUtFIG9yIENoaWxkIFNBIHJl a2V5LCB0aGUNCiAgIFNBIGFuZCBUUyBwYXlsb2FkcyBjYW4gYmUgb21pdGVkLiAgRm9yIGFuIElL RSBTQSByZWtleSwgaW5zdGVhZCBvZg0KICAgdGhlIChsYXJnZSkgU0EgcGF5bG9hZCwgb25seSBh IEtleSBFeGNoYW5nZSAoS0UpIHBheWxvYWQgYW5kIGEgbmV3DQogICBOb3RpZnkgVHlwZSBwYXls b2FkIHdpdGggdGhlIG5ldyBTUEkgaXMgcmVxdWlyZWQuICBGb3IgYSBDaGlsZCBTQQ0KICAgcGF5 bG9hZCwgaW5zdGVhZCBvZiB0aGUgU0Egb3IgVFMgcGF5bG9hZHMsIG9ubHkgYW4gb3B0aW9uYWwg Tm9uY2UNCiAgIHBheWxvYWQgKHdoZW4gdXNpbmcgUEZTKSBhbmQgYSBuZXcgTm90aWZ5IFR5cGUg cGF5bG9hZCB3aXRoIHRoZSBuZXcNCiAgIFNQSSBpcyBuZWVkZWQuICBUaGlzIG1ha2VzIHRoZSBy ZWtleSBleGNoYW5nZSBwYWNrZXRzIG11Y2ggc21hbGxlcg0KICAgYW5kIHRoZSBwZWVycyBkbyBu b3QgbmVlZCB0byB2ZXJpZnkgdGhhdCB0aGUgU0Egb3IgVFMgcGFyYW1ldGVycyBhcmUNCiAgIGNv bXBhdGlibGUgd2l0aCB0aGUgb2xkIFNBLg0KDQoyLiAgQ29udmVudGlvbnMgVXNlZCBpbiBUaGlz IERvY3VtZW50DQoNCjIuMS4gIFJlcXVpcmVtZW50cyBMYW5ndWFnZQ0KDQogICBUaGUga2V5IHdv cmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIs DQogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTk9UIFJFQ09NTUVO REVEIiwgIk1BWSIsIGFuZA0KICAgIk9QVElPTkFMIiBpbiB0aGlzIGRvY3VtZW50IGFyZSB0byBi ZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gQkNQDQogICAxNCBbUkZDMjExOV0gW1JGQzgx NzRdIHdoZW4sIGFuZCBvbmx5IHdoZW4sIHRoZXkgYXBwZWFyIGluIGFsbA0KICAgY2FwaXRhbHMs IGFzIHNob3duIGhlcmUuDQoNCjMuICBOZWdvdGlhdGlvbiBvZiBTdXBwb3J0IGZvciBPUFRJTUla RUQgUkVLRVkNCg0KICAgVG8gaW5kaWNhdGUgc3VwcG9ydCBmb3IgdGhlIG9wdGltaXplZCByZWtl eSBuZWdvdGlhdGlvbiwgdGhlDQogICBpbml0aWF0b3IgaW5jbHVkZXMgdGhlIE9QVElNSVpFRF9S RUtFWV9TVVBQT1JURUQgTm90aWZ5IHBheWxvYWQgaW4NCiAgIHRoZSBJS0VfQVVUSCBleGNoYW5n ZSByZXF1ZXN0LiAgQSByZXNwb25kZXIgdGhhdCBzdXBwb3J0cyB0aGUNCiAgIG9wdGltaXplZCBy ZWtleSBleGNoYW5nZSBpbmNsdWVzIHRoZSBPUFRJTUlaRURfUkVLRVlfU1VQUE9SVEVEIE5vdGlm eQ0KICAgcGF5bG9hZCBpbiBpdHMgcmVzcG9uc2UuICBOb3RlIHRoYXQgdGhlIG5vdGlmeSBpbmRp Y2lhdGVzIHN1cHBvcnQgZm9yDQogICBvcHRpbWl6ZWQgcmVrZXkgZm9yIGJvdGggSUtFIGFuZCBD aGlsZCBTQXMuDQoNCg0KDQoNCg0KS2FtcGF0aSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgMTIg SmFudWFyeSAyMDIyICAgICAgICAgICAgICAgIFtQYWdlIDNdDQoMDQpJbnRlcm5ldC1EcmFmdCAg ICAgSUtFdjIgT3B0aW9uYWwgQ2hpbGQgU0EmVFMgUGF5bG9hZHMgICAgICAgICBKdWx5IDIwMjEN Cg0KDQogICBXaGVuIGEgcGVlciB3aXNoZXMgdG8gcmVrZXkgYW4gSUtFIFNBIG9yIENoaWxkIFNB LCBpdCBNQVkgdXNlIHRoZQ0KICAgb3B0aW1pemVkIHJla2V5IG1ldGhvZCBkdXJpbmcgdGhlIENS RUFURV9DSElMRF9TQSBleGNoYW5nZS4gIEENCiAgIHJlc3BvbmRlciBNVVNUIGFjY2VwdCB0aGF0 IHRoZSBpbml0aWF0b3IgdXNlcyBhIHJlZ3VsYXIgb3Igb3B0aW1pemVkDQogICByZWV5Lg0KDQog ICBUaGUgaW5pdGlhdG9yIGluZGljYXRlcyBpdHMgc3VwcG9ydCBmb3Igb3B0aW1pemluZyBwYXls b2FkcyBhdA0KICAgcmVrZXlpbmcgSUtFIFNBcyBhbmQgQ2hpbGQgU0FzIGJ5IGluY2x1ZGluZyBh IE5vdGlmeSBwYXlsb2FkIG9mIHR5cGUNCiAgIE1JTklNQUxfUkVLRVlfU1VQUE9SVEVEIGluIHRo ZSBJS0VfQVVUSCByZXF1ZXN0IG1lc3NhZ2UuICBCeQ0KICAgb2JzZXJ2aW5nIHRoZSBNSU5JTUFM X1JFS0VZX1NVUFBPUlRFRCBub3RpZmljYXRpb24gaW4gdGhlIHJlY2VpdmVkDQogICBtZXNzYWdl LCB0aGUgcmVzcG9uZGVyIGNhbiBkZWR1Y2UgdGhlIGluaXRpYXRvcidzIHN1cHBvcnQgb2YgdGhp cw0KICAgZXh0ZW5zaW9uLiAgSWYgdGhlIHJlc3BvbmRlciBhbHNvIHN1cHBvcnRzIHRoaXMgZXh0 ZW5zaW9uLCBpdA0KICAgaW5jbHVkZXMgdGhlIE1JTklNQUxfUkVLRVlfU1VQUE9SVEVEIG5vdGlm aWNhdGlvbiBpbiB0aGUNCiAgIGNvcnJlc3BvbmRpbmcgcmVzcG9uc2UgbWVzc2FnZS4gIEFmdGVy IHJlY2VpdmluZyB0aGUgcmVzcG9uc2UNCiAgIG1lc3NhZ2UsIHRoZSBpbml0aWF0b3IgY2FuIGFs c28ga25vdyB0aGUgc3VwcG9ydCBvZiB0aGlzIGV4dGVuc2lvbiBvZg0KICAgdGhlIHJlc3BvbmRl ciBzaWRlLg0KDQogICBUaGUgSUtFX0FVVEggbWVzc2FnZSBleGNoYW5nZSBpbiB0aGlzIGNhc2Ug aXMgc2hvd24gYmVsb3c6DQoNCiAgIEluaXRpYXRvciAgICAgICAgICAgICAgICAgICAgICAgICBS ZXNwb25kZXINCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICBIRFIsIFNLIHtJRGksIFtDRVJULF0gW0NFUlRS RVEsXQ0KICAgICAgIFtJRHIsXSBBVVRILCBTQWkyLCBUU2ksIFRTciwNCiAgICAgICBOKE9QVElN SVpFRF9SRUtFWV9TVVBQT1JURUQpfSAtLT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDwtLSBIRFIsIFNLIHtJRHIsIFtDRVJULF0gQVVUSCwNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgU0FyMiwgVFNpLCBUU3IsDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIE4oT1BUSU1JWkVEX1JFS0VZX1NVUFBPUlRFRCl9DQoNCiAg IElmIHRoZSByZXNwb25kZXIgZG9lcyBub3Qgc3VwcG9ydCB0aGlzIGV4dGVuc2lvbiwgYXMgcGVy IHJlZ3VsYXINCiAgIElLRXYyIHByb2Nlc3NpbmcsIGl0IE1VU1QgaWdub3JlIHRoZSB1bmtub3du IE5vdGlmeSBwYXlsb2FkLiAgVGhlDQogICBpbml0aWF0b3Igd2lsbCBub3RpY2UgdGhlIGxhY2sg b2YgdGhlIE9QVElNSVpFRF9SRUtFWV9TVVBQT1JURUQNCiAgIE5vdGlmeSBpbiB0aGUgcmVwbHkg YW5kIHRodXMga25vdyBpdCBjYW5ub3QgdXNlIHRoZSBvcHRpbWl6ZWQgcmVrZXkNCiAgIG1ldGhv ZC4NCg0KICAgVGhlIElLRV9BVVRIIG1lc3NhZ2UgZXhjaGFuZ2UgaW4gdGhpcyBjYXNlIGlzIHNo b3duIGJlbG93Og0KDQo0LiAgT3B0aW1pemVkIFJla2V5IG9mIHRoZSBJS0UgU0ENCg0KICAgVGhl IGluaXRpYXRvciBvZiBhbiBvcHRpbWl6ZWQgcmVrZXkgcmVxdWVzdCBzZW5kcyBhIENSRUFURV9D SElMRF9TQQ0KICAgcGF5bG9hZCB3aXRoIHRoZSBPUFRJTUlaRURfUkVLRVkgbm90aWZ5IHBheWxv YWQgY29udGFpbmluZyB0aGUgbmV3DQogICBTZWN1cml0eSBQYXJhbWV0ZXIgSW5kZXggKFNQSSkg Zm9yIHRoZSBuZXcgSUtFIFNBLiAgSXQgb21pdHMgdGhlIFNBDQogICBwYXlsb2FkLg0KDQogICBU aGUgcmVzcG9uZGVyIG9mIGFuIG9wdGltaXplZCByZWtleSByZXF1ZXN0IHBlcmZvcm1zIHRoZSBz YW1lDQogICBwcm9jZXNzLiAgSXQgaW5jbHVkZXMgdGhlIE9QVElNSVpFRF9SRUtFWSBub3RpZnkg d2l0aCBpdHMgbmV3IElLRSBTUEkNCiAgIGFuZCBvbWl0cyB0aGUgU0EgcGF5bG9hZC4NCg0KICAg Qm90aCBwYXJ0aWVzIHNlbmQgTm9uY2UgYW5kIEtFIHBheWxvYWRzIGp1c3QgYXMgdGhleSB3b3Vs ZCBkbyBmb3IgYQ0KICAgcmVndWxhciBJS0UgU0EgcmVrZXkuDQoNCg0KDQpLYW1wYXRpLCBldCBh bC4gICAgICAgICAgRXhwaXJlcyAxMiBKYW51YXJ5IDIwMjIgICAgICAgICAgICAgICAgW1BhZ2Ug NF0NCgwNCkludGVybmV0LURyYWZ0ICAgICBJS0V2MiBPcHRpb25hbCBDaGlsZCBTQSZUUyBQYXls b2FkcyAgICAgICAgIEp1bHkgMjAyMQ0KDQoNCiAgIFRoZSBDUkVBVEVfQ0hJTERfU0EgbWVzc2Fn ZSBleGNoYW5nZSBpbiB0aGlzIGNhc2UgaXMgc2hvd24gYmVsb3c6DQoNCiAgIEluaXRpYXRvciAg ICAgICAgICAgICAgICAgICAgICAgICBSZXNwb25kZXINCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICBIRFIs IFNLIHtOKE9QVElNSVpFRF9SRUtFWSksDQogICAgICAgTmksIEtFaX0gLS0+DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8LS0gSERSLCBTSyB7TihPUFRJTUlaRURfUkVLRVkpLA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOciwgS0VyfQ0KDQo1LiAg T3B0aW1pemVkIFJla2V5IG9mIENoaWxkIFNBcw0KDQogICBUaGUgaW5pdGlhdG9yIG9mIGFuIG9w dGltaXplZCByZWtleSByZXF1ZXN0IHNlbmRzIGEgQ1JFQVRFX0NISUxEX1NBDQogICBwYXlsb2Fk IHdpdGggdGhlIE9QVElNSVpFRF9SRUtFWSBub3RpZnkgcGF5bG9hZCBjb250YWluaW5nIHRoZSBu ZXcNCiAgIFNlY3VyaXR5IFBhcmFtZXRlciBJbmRleCAoU1BJKSBmb3IgdGhlIG5ldyBDaGlsZCBT QS4gIEl0IG9taXRzIHRoZSBTQQ0KICAgcGF5bG9hZC4gIElmIHRoZSBjdXJyZW50IENoaWxkIFNB IHdhcyBuZWdvdGlhdGVkIHdpdGggUGVyZmVjdCBGb3J3YXJkDQogICBTZWNyZWN5IChQRlMpLCBh IEtFaSBwYXlsb2FkIE1VU1QgYmUgaW5jbHVkZWQgYXMgd2VsbC4gIElmIG5vIFBGUyB3YXMNCiAg IG5lZ290aWF0ZWQgZm9yIHRoZSBjdXJyZW50IENoaWxkIFNBLCBhIEtFaSBwYXlsb2FkIE1VU1Qg Tk9UIGJlDQogICBpbmNsdWRlZC4NCg0KICAgVGhlIHJlc3BvbmRlciBvZiBhbiBvcHRpbWl6ZWQg cmVrZXkgcmVxdWVzdCBwZXJmb3JtcyB0aGUgc2FtZQ0KICAgcHJvY2Vzcy4gIEl0IGluY2x1ZGVz IHRoZSBPUFRJTUlaRURfUkVLRVkgbm90aWZ5IHdpdGggaXRzIG5ldyBJS0UgU1BJDQogICBhbmQg b21pdHMgdGhlIFNBIGFuZCBUUyBwYXlsb2Fkcy4gIERlcGVuZGluZyBvbiB0aGUgUEZTIG5lZ290 aWF0aW9uDQogICBvZiB0aGUgY3VycmVudCBDaGlsZCBTQSwgdGhlIHJlc3BvbmRlciBpbmNsdWRl cyBhIEtFciBwYXlsb2FkLg0KDQogICBCb3RoIHBhcnRpZXMgc2VuZCBOb25jZSBwYXlsb2FkcyBq dXN0IGFzIHRoZXkgd291bGQgZG8gZm9yIGEgcmVndWxhcg0KICAgQ2hpbGQgU0EgcmVrZXkuDQoN CiAgIFVzaW5nIHRoZSByZWNlaXZlZCBvbGQgU1BJIGZyb20gdGhlIFJFS0VZX1NBIHBheWxvYWQg YW5kIHRoZSBuZXcgU1BJDQogICByZWNlaXZlZCBmcm9tIHRoZSBPUFRJTUlaRURfUkVLRVkgcGF5 bG9hZCwgYm90aCBwYXJ0aWVzIGNhbiBwZXJmb3JtDQogICB0aGUgQ2hpbGQgU0EgcmVrZXkgb3Bl cmF0aW9uLg0KDQogICBUaGUgQ1JFQVRFX0NISUxEX1NBIG1lc3NhZ2UgZXhjaGFuZ2UgaW4gdGhp cyBjYXNlIGlzIHNob3duIGJlbG93Og0KDQogICBJbml0aWF0b3IgICAgICAgICAgICAgICAgICAg ICAgICAgUmVzcG9uZGVyDQogICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgSERSLCBTSyB7TihSRUtFWV9TQSks IE4oT1BUSU1JWkVEX1JFS0VZKSwNCiAgICAgICBOaSwgW0tFaSxdfSAtLT4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDwtLSBIRFIsIFNLIHtOKE9QVElNSVpFRF9SRUtFWSksDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5yLCBbS0VyLF19DQoNCjYu ICBQYXlsb2FkIEZvcm1hdHMNCg0KNi4xLiAgT1BUSU1JWkVEX1JFS0VZX1NVUFBPUlRFRCBOb3Rp ZnkNCg0KICAgVGhlIE9QVElNSVpFRF9SRUtFWV9TVVBQT1JURUQgTm90aWZ5IE1lc3NhZ2UgdHlw ZSBub3RpZmljYXRpb24gaXMNCiAgIHVzZWQgYnkgdGhlIGluaXRpYXRvciBhbmQgcmVzcG9uZGVy IHRvIGluZGljYXRlIHRoZWlyIHN1cHBvcnQgZm9yIHRoZQ0KICAgb3B0aW1pemVkIHJla2V5IG5l Z290YXRpb24uDQoNCg0KDQoNCkthbXBhdGksIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIDEyIEph bnVhcnkgMjAyMiAgICAgICAgICAgICAgICBbUGFnZSA1XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAg IElLRXYyIE9wdGlvbmFsIENoaWxkIFNBJlRTIFBheWxvYWRzICAgICAgICAgSnVseSAyMDIxDQoN Cg0KICAgICAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAg ICAgICAgICAgIDMNCiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkg MCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8IE5leHQgUGF5bG9hZCAg fEN8ICBSRVNFUlZFRCAgIHwgICAgICAgICBQYXlsb2FkIExlbmd0aCAgICAgICAgfA0KICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsNCiAgIHxQcm90b2NvbCBJRCg9MCl8IFNQSSBTaXplICg9MCkgfCAgICAgIE5vdGlmeSBN ZXNzYWdlIFR5cGUgICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQogICAqICBQcm90b2NvbCBJRCAoMSBv Y3RldCkgLSBNVVNUIGJlIDAuDQoNCiAgICogIFNQSSBTaXplICgxIG9jdGV0KSAtIE1VU1QgYmUg MCwgbWVhbmluZyBubyBTUEkgaXMgcHJlc2VudC4NCg0KICAgKiAgTm90aWZ5IE1lc3NhZ2UgVHlw ZSAoMiBvY3RldHMpIC0gTVVTVCBiZSB0aGUgdmFsdWUgW1RCRDFdLg0KDQogICBUaGlzIE5vdGlm eSBNZXNzYWdlIHR5cGUgY29udGFpbnMgbm8gZGF0YS4NCg0KNi4yLiAgT1BUSU1JWkVEX1JFS0VZ IE5vdGlmeQ0KDQogICBUaGUgT1BUSU1JWkVEX1JFS0VZIE5vdGlmeSBNZXNzYWdlIHR5cGUgaXMg dXNlZCB0byBwZXJmb3JtIGFuDQogICBvcHRpbWl6ZWQgSUtFIFNBIG9yIENoaWxkIFNBIHJla2V5 Lg0KDQogICAgMCAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAg ICAgICAgICAgIDMNCiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkg MCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8IE5leHQgUGF5bG9hZCAg fEN8ICBSRVNFUlZFRCAgIHwgICAgICAgICBQYXlsb2FkIExlbmd0aCAgICAgICAgfA0KICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsNCiAgIHxQcm90b2NvbCBJRCAgICB8IFNQSSBTaXplICg9OCkgfCAgICAgIE5vdGlmeSBN ZXNzYWdlIFR5cGUgICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgICAgICAgICAgICAgICBTZWN1 cml0eSBQYXJhbWV0ZXIgSW5kZXggKFNQSSkgICAgICAgICAgICAgICAgIHwNCiAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KDQogICAqICBQcm90b2NvbCBJRCAoMSBvY3RldCkgLSBNVVNUIGJlIDEu DQoNCiAgICogIFNQSSBTaXplICgxIG9jdGV0KSAtIE1VU1QgYmUgOCB3aGVuIHJla2V5aW5nIGFu IElLRSBTQXMuICBNVVNUIGJlDQogICAgICA0IHdoZW4gcmVrZXlpbmcgYSBDaGlsZCBTQS4NCg0K ICAgKiAgTm90aWZ5IE1lc3NhZ2UgVHlwZSAoMiBvY3RldHMpIC0gTVVTVCBiZSBzZXQgdG8gdGhl IHZhbHVlIFtUQkQyXS4NCg0KICAgKiAgU1BJICg0IG9jdGV0cyBvciA4IG9jdGV0cykgLSBTZWN1 cml0eSBQYXJhbWV0ZXIgSW5kZXguICBUaGUgcGVlcidzDQogICAgICBuZXcgU1BJLg0KDQo3LiAg SUFOQSBDb25zaWRlcmF0aW9ucw0KDQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgdHdvIG5ldyBO b3RpZnkgTWVzc2FnZSBUeXBlcyBpbiB0aGUgIklLRXYyDQogICBOb3RpZnkgTWVzc2FnZSBUeXBl cyAtIFN0YXR1cyBUeXBlcyIgcmVnaXN0cnkuICBJQU5BIGlzIHJlcXVlc3RlZCB0bw0KICAgYXNz aWduIGNvZGVwb2ludHMgaW4gdGhpcyByZWdpc3RyeS4NCg0KDQoNCg0KS2FtcGF0aSwgZXQgYWwu ICAgICAgICAgIEV4cGlyZXMgMTIgSmFudWFyeSAyMDIyICAgICAgICAgICAgICAgIFtQYWdlIDZd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgSUtFdjIgT3B0aW9uYWwgQ2hpbGQgU0EmVFMgUGF5bG9h ZHMgICAgICAgICBKdWx5IDIwMjENCg0KDQogICBOT1RJRlkgbWVzc2FnZXM6IHN0YXR1cyB0eXBl cyAgICAgICAgICAgIFZhbHVlDQogICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICBPUFRJTUlaRURfUkVLRVlfU1VQUE9SVEVEICAg ICAgICAgICAgICAgICAgVEJEMQ0KICAgT1BUSU1JWkVEX1JFS0VZICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFRCRDINCg0KOC4gIE9wZXJhdGlvbmFsIENvbnNpZGVyYXRpb25zDQoNCiAgIFNv bWUgaW1wbGVtZW50YXRpb25zIGFsbG93IHNlbmRpbmcgcmVrZXkgbWVzc2FnZXMgd2l0aCBhIGRp ZmZlcmVudA0KICAgc2V0IG9mIFRyYWZmaWMgU2VsZWN0b3JzIG9yIGNyeXB0b2dyYXBoaWMgcGFy YW1ldGVycyBpbiByZXNwb25zZSB0byBhDQogICBjb25maWd1cmF0aW9uIHVwZGF0ZS4gIElLRXYy IHN0YXRlcyB0aGlzIFNIT1VMRCBOT1QgYmUgZG9uZS4gIFdoZXRoZXINCiAgIG9yIG5vdCBvcHRp bWl6ZWQgcmVrZXlpbmcgaXMgdXNlZCwgYSBjb25maWd1cmF0aW9uIGNoYW5nZSB0aGF0DQogICBj aGFuZ2VzIHRoZSBUcmFmZmljIFNlbGVjdG9ycyBvciBjcnlwdG9ncmFwaGljIHBhcmFtZXRlcnMg TVVTVCBOT1QNCiAgIHVzZSB0aGUgb3B0aW1pemVkIHJla2V5IG1ldGhvZC4gIEl0IFNIT1VMRCBh bHNvIG5vdCB1c2UgYSByZWd1bGFyDQogICByZWtleSBtZXRob2QgYnV0IGluc3RlYWQgc3RhcnQg YW4gZW50aXJlIG5ldyBJS0UgYW5kIENoaWxkIFNBDQogICBuZWdvdGlhdGlvbiB3aXRoIHRoZSBu ZXcgcGFyYW1ldGVycy4NCg0KOS4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQoNCiAgIFRoZSBv cHRpbWl6ZWQgcmVrZXkgcmVtb3ZlcyBzZW5kaW5nIHVubmVjY2Vzc2FyeSBuZXcgcGFyYW1ldGVy cyB0aGF0DQogICBvcmlnaW5hbGx5IHdvdWxkIGhhdmUgdG8gYmUgdmFsaWRhdGVkIGFnYWluc3Qg dGhlIG9yaWdpbmFsDQogICBwYXJhbWV0ZXJzLiAgSW4gdGhhdCBzZW5zZSwgdGhpcyBvcHRpbWFs aXphdGlvbiBlbmhhbmNlcyB0aGUgc2VjdXJpdHkNCiAgIG9mIHRoZSByZWtleSBwcm9jZXNzLg0K DQoxMC4gIEFja25vd2xlZGdtZW50cw0KDQogICBTcGVjaWFsIHRoYW5rcyBnbyB0byBQYXVsIFdv dXRlcnMsIFZhbGVyeSBTbXlzbG92LCBhbmQgQW50b255IEFudG9ueS4NCg0KMTEuICBOb3JtYXRp dmUgUmVmZXJlbmNlcw0KDQogICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZv ciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQ0KICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZl bHMiLCBCQ1AgMTQsIFJGQyAyMTE5LA0KICAgICAgICAgICAgICBET0kgMTAuMTc0ODcvUkZDMjEx OSwgTWFyY2ggMTk5NywNCiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3Jn L2luZm8vcmZjMjExOT4uDQoNCiAgIFtSRkM3Mjk2XSAgS2F1Zm1hbiwgQy4sIEhvZmZtYW4sIFAu LCBOaXIsIFkuLCBFcm9uZW4sIFAuLCBhbmQgVC4NCiAgICAgICAgICAgICAgS2l2aW5lbiwgIklu dGVybmV0IEtleSBFeGNoYW5nZSBQcm90b2NvbCBWZXJzaW9uIDINCiAgICAgICAgICAgICAgKElL RXYyKSIsIFNURCA3OSwgUkZDIDcyOTYsIERPSSAxMC4xNzQ4Ny9SRkM3Mjk2LCBPY3RvYmVyDQog ICAgICAgICAgICAgIDIwMTQsIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzcy OTY+Lg0KDQogICBbUkZDODE3NF0gIExlaWJhLCBCLiwgIkFtYmlndWl0eSBvZiBVcHBlcmNhc2Ug dnMgTG93ZXJjYXNlIGluIFJGQw0KICAgICAgICAgICAgICAyMTE5IEtleSBXb3JkcyIsIEJDUCAx NCwgUkZDIDgxNzQsIERPSSAxMC4xNzQ4Ny9SRkM4MTc0LA0KICAgICAgICAgICAgICBNYXkgMjAx NywgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjODE3ND4uDQoNCkF1dGhvcnMn IEFkZHJlc3Nlcw0KDQogICBTYW5kZWVwIEthbXBhdGkNCiAgIEh1YXdlaSBUZWNobm9sb2dpZXMN CiAgIERpdnlhc2hyZWUgVGVjaG5vIFBhcmssIFdoaXRlZmllbGQNCg0KDQoNCkthbXBhdGksIGV0 IGFsLiAgICAgICAgICBFeHBpcmVzIDEyIEphbnVhcnkgMjAyMiAgICAgICAgICAgICAgICBbUGFn ZSA3XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgIElLRXYyIE9wdGlvbmFsIENoaWxkIFNBJlRTIFBh eWxvYWRzICAgICAgICAgSnVseSAyMDIxDQoNCg0KICAgQmFuZ2Fsb3JlIDU2MDA2Ng0KICAgS2Fy bmF0YWthDQogICBJbmRpYQ0KDQogICBFbWFpbDogc2FuZGVlcGthbXBhdGlAaHVhd2VpLmNvbQ0K DQoNCiAgIFdlaSBQYW4NCiAgIEh1YXdlaSBUZWNobm9sb2dpZXMNCiAgIDEwMSBTb2Z0d2FyZSBB dmVudWUsIFl1aHVhdGFpIERpc3RyaWN0DQogICBOYW5qaW5nDQogICBKaWFuZ3N1LA0KICAgQ2hp bmENCg0KICAgRW1haWw6IHdpbGxpYW0ucGFud2VpQGh1YXdlaS5jb20NCg0KDQogICBNZWR1cmkg UyBTIEJoYXJhdGgNCiAgIE1hdmVuaXIgU3lzdGVtcyBQdnQgTHRkDQogICBNYW55YXRhIFRlY2gg UGFyaw0KICAgQmFuZ2Fsb3JlDQogICBLYXJuYXRha2ENCiAgIEluZGlhDQoNCiAgIEVtYWlsOiBi aGFyYXRoLm1lZHVyaUBtYXZlbmlyLmNvbQ0KDQoNCiAgIE1laWxpbmcgQ2hlbg0KICAgQ2hpbmEg TW9iaWxlDQogICAzMiBYdWFud3VtZW4gV2VzdCBTdHJlZXQsIFdlc3QgRGlzdHJpY3QNCiAgIEJl aWppbmcNCiAgIEJlaWppbmcsIDEwMDA1Mw0KICAgQ2hpbmENCg0KICAgRW1haWw6IGNoZW5tZWls aW5nQGNoaW5hbW9iaWxlLmNvbQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpLYW1w YXRpLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyAxMiBKYW51YXJ5IDIwMjIgICAgICAgICAgICAg ICAgW1BhZ2UgOF0NCg== --000000000000fcb07505c6e4da6d Content-Type: text/xml; charset="US-ASCII"; name="draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05-pw.xml" Content-Disposition: attachment; filename="draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05-pw.xml" Content-Transfer-Encoding: base64 Content-ID: <17a98ca137d4593ca9a2> X-Attachment-Id: 17a98ca137d4593ca9a2 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCiAgPD94bWwtc3R5bGVzaGVl dCB0eXBlPSJ0ZXh0L3hzbCIgaHJlZj0icmZjMjYyOS54c2x0IiA/Pg0KICA8IS0tIGdlbmVyYXRl ZCBieSBodHRwczovL2dpdGh1Yi5jb20vY2Fiby9rcmFtZG93bi1yZmMyNjI5IHZlcnNpb24gMS4z LjI0IC0tPg0KDQo8IURPQ1RZUEUgcmZjIFNZU1RFTSAicmZjMjYyOS5kdGQiIFsNCl0+DQoNCjw/ cmZjIHRvYz0ieWVzIj8+DQo8P3JmYyBzb3J0cmVmcz0ieWVzIj8+DQo8P3JmYyBzeW1yZWZzPSJ5 ZXMiPz4NCg0KPHJmYyBpcHI9InRydXN0MjAwOTAyIiBjb25zZW5zdXM9InRydWUiIGRvY05hbWU9 ImRyYWZ0LWthbXBhdGktaXBzZWNtZS1pa2V2Mi1zYS10cy1wYXlsb2Fkcy1vcHQtMDUiIGNhdGVn b3J5PSJzdGQiPg0KDQogIDxmcm9udD4NCiAgICA8dGl0bGUgYWJicmV2PSJJS0V2MiBPcHRpb25h bCBDaGlsZCBTQSZhbXA7VFMgUGF5bG9hZHMiPklLRXYyIE9wdGlvbmFsIFNBJmFtcDtUUyBQYXls b2FkcyBpbiBDaGlsZCBFeGNoYW5nZTwvdGl0bGU+DQoNCiAgICA8YXV0aG9yIGluaXRpYWxzPSJT LiIgc3VybmFtZT0iS2FtcGF0aSIgZnVsbG5hbWU9IlNhbmRlZXAgS2FtcGF0aSI+DQogICAgICA8 b3JnYW5pemF0aW9uIGFiYnJldj0iSHVhd2VpIj5IdWF3ZWkgVGVjaG5vbG9naWVzPC9vcmdhbml6 YXRpb24+DQogICAgICA8YWRkcmVzcz4NCiAgICAgICAgPHBvc3RhbD4NCiAgICAgICAgICA8c3Ry ZWV0PkRpdnlhc2hyZWUgVGVjaG5vIFBhcmssIFdoaXRlZmllbGQ8L3N0cmVldD4NCiAgICAgICAg ICA8Y2l0eT5CYW5nYWxvcmU8L2NpdHk+DQogICAgICAgICAgPHJlZ2lvbj5LYXJuYXRha2E8L3Jl Z2lvbj4NCiAgICAgICAgICA8Y29kZT41NjAwNjY8L2NvZGU+DQogICAgICAgICAgPGNvdW50cnk+ SW5kaWE8L2NvdW50cnk+DQogICAgICAgIDwvcG9zdGFsPg0KICAgICAgICA8ZW1haWw+c2FuZGVl cGthbXBhdGlAaHVhd2VpLmNvbTwvZW1haWw+DQogICAgICA8L2FkZHJlc3M+DQogICAgPC9hdXRo b3I+DQogICAgPGF1dGhvciBpbml0aWFscz0iVy4iIHN1cm5hbWU9IlBhbiIgZnVsbG5hbWU9Ildl aSBQYW4iPg0KICAgICAgPG9yZ2FuaXphdGlvbiBhYmJyZXY9Ikh1YXdlaSI+SHVhd2VpIFRlY2hu b2xvZ2llczwvb3JnYW5pemF0aW9uPg0KICAgICAgPGFkZHJlc3M+DQogICAgICAgIDxwb3N0YWw+ DQogICAgICAgICAgPHN0cmVldD4xMDEgU29mdHdhcmUgQXZlbnVlLCBZdWh1YXRhaSBEaXN0cmlj dDwvc3RyZWV0Pg0KICAgICAgICAgIDxjaXR5Pk5hbmppbmc8L2NpdHk+DQogICAgICAgICAgPHJl Z2lvbj5KaWFuZ3N1PC9yZWdpb24+DQogICAgICAgICAgPGNvZGU+PC9jb2RlPg0KICAgICAgICAg IDxjb3VudHJ5PkNoaW5hPC9jb3VudHJ5Pg0KICAgICAgICA8L3Bvc3RhbD4NCiAgICAgICAgPGVt YWlsPndpbGxpYW0ucGFud2VpQGh1YXdlaS5jb208L2VtYWlsPg0KICAgICAgPC9hZGRyZXNzPg0K ICAgIDwvYXV0aG9yPg0KICAgIDxhdXRob3IgaW5pdGlhbHM9Ik0uIiBzdXJuYW1lPSJCaGFyYXRo IiBmdWxsbmFtZT0iTWVkdXJpIFMgUyBCaGFyYXRoIj4NCiAgICAgIDxvcmdhbml6YXRpb24gYWJi cmV2PSJNYXZlbmlyIj5NYXZlbmlyIFN5c3RlbXMgUHZ0IEx0ZDwvb3JnYW5pemF0aW9uPg0KICAg ICAgPGFkZHJlc3M+DQogICAgICAgIDxwb3N0YWw+DQogICAgICAgICAgPHN0cmVldD5NYW55YXRh IFRlY2ggUGFyazwvc3RyZWV0Pg0KICAgICAgICAgIDxjaXR5PkJhbmdhbG9yZTwvY2l0eT4NCiAg ICAgICAgICA8cmVnaW9uPkthcm5hdGFrYTwvcmVnaW9uPg0KICAgICAgICAgIDxjb2RlPjwvY29k ZT4NCiAgICAgICAgICA8Y291bnRyeT5JbmRpYTwvY291bnRyeT4NCiAgICAgICAgPC9wb3N0YWw+ DQogICAgICAgIDxlbWFpbD5iaGFyYXRoLm1lZHVyaUBtYXZlbmlyLmNvbTwvZW1haWw+DQogICAg ICA8L2FkZHJlc3M+DQogICAgPC9hdXRob3I+DQogICAgPGF1dGhvciBpbml0aWFscz0iTS4iIHN1 cm5hbWU9IkNoZW4iIGZ1bGxuYW1lPSJNZWlsaW5nIENoZW4iPg0KICAgICAgPG9yZ2FuaXphdGlv biBhYmJyZXY9IkNNQ0MiPkNoaW5hIE1vYmlsZTwvb3JnYW5pemF0aW9uPg0KICAgICAgPGFkZHJl c3M+DQogICAgICAgIDxwb3N0YWw+DQogICAgICAgICAgPHN0cmVldD4zMiBYdWFud3VtZW4gV2Vz dCBTdHJlZXQsIFdlc3QgRGlzdHJpY3Q8L3N0cmVldD4NCiAgICAgICAgICA8Y2l0eT5CZWlqaW5n PC9jaXR5Pg0KICAgICAgICAgIDxyZWdpb24+QmVpamluZzwvcmVnaW9uPg0KICAgICAgICAgIDxj b2RlPjEwMDA1MzwvY29kZT4NCiAgICAgICAgICA8Y291bnRyeT5DaGluYTwvY291bnRyeT4NCiAg ICAgICAgPC9wb3N0YWw+DQogICAgICAgIDxlbWFpbD5jaGVubWVpbGluZ0BjaGluYW1vYmlsZS5j b208L2VtYWlsPg0KICAgICAgPC9hZGRyZXNzPg0KICAgIDwvYXV0aG9yPg0KDQogICAgPGRhdGUg eWVhcj0iMjAyMSIvPg0KDQogICAgPGFyZWE+U2VjdXJpdHk8L2FyZWE+DQogICAgPHdvcmtncm91 cD5JUFNFQ01FIFdvcmtpbmcgR3JvdXA8L3dvcmtncm91cD4NCiAgICA8a2V5d29yZD5JbnRlcm5l dC1EcmFmdDwva2V5d29yZD4NCg0KICAgIDxhYnN0cmFjdD4NCg0KPHQ+VGhpcyBkb2N1bWVudCBk ZXNjcmliZXMgYSBtZXRob2QgZm9yIHJlZHVjaW5nIHRoZSBzaXplIG9mIHRoZQ0KSW50ZXJuZXQg S2V5IEV4Y2hhbmdlIHZlcnNpb24gMiAoSUtFdjIpIENSRUFURV9DSElMRF9TQSBleGNoYW5nZXMN CnVzZWQgZm9yIHJla2V5aW5nIG9mIHRoZSBJS0Ugb3IgQ2hpbGQgU0EgYnkgcmVwbGFjaW5nIHRo ZSBTQSBhbmQgVFMNCnBheWxvYWRzIHdpdGggYSBOb3RpZnkgTWVzc2FnZSBwYXlsb2FkLiBSZWR1 Y2luZyBzaXplIGFuZCBjb21wbGV4aXR5DQpvZiBJS0V2MiBleGNoYW5nZXMgaXMgZXNwZWNpYWxs eSB1c2VmdWwgZm9yIGxvdyBwb3dlciBjb25zdW1wdGlvbg0KYmF0dGVyeSBwb3dlcmVkIGRldmlj ZXMuPC90Pg0KDQogICAgPC9hYnN0cmFjdD4NCiAgPC9mcm9udD4NCiAgPG1pZGRsZT4NCg0KPHNl Y3Rpb24gYW5jaG9yPSJpbnRyb2R1Y3Rpb24iIHRpdGxlPSJJbnRyb2R1Y3Rpb24iPg0KDQo8dD5U aGUgSW50ZXJuZXQgS2V5IEV4Y2hhbmdlIHByb3RvY29sIHZlcnNpb24gMiAoSUtFdjIpIDx4cmVm IHRhcmdldD0iUkZDNzI5NiI+PC94cmVmPg0KaXMgdXNlZCB0byBuZWdvdGlhdGUgU2VjdXJpdHkg QXNzb2NpYXRpb24gKFNBKSBwYXJhbWV0ZXJzIGZvciB0aGUgSUtFDQpTQSBhbmQgdGhlIENoaWxk IFNBcy4gQ3J5cHRvZ3JhcGhpYyBrZXkgbWF0ZXJpYWwgZm9yIHRoZXNlIFNBcyBoYXZlIGENCmxp bWl0ZWQgbGlmZXRpbWUgYmVmb3JlIGl0IG5lZWRzIHRvIGJlIHJlZnJlc2hlcywgYSBwcm9jZXNz IHJlZmVycmVkIHRvDQphcyAicmVrZXlpbmciLiBJS0V2MiB1c2VzIHRoZSBDUkVBVEVfQ0hJTERf U0EgZXhjaGFuZ2UgdG8gcmVrZXkgZWl0aGVyDQp0aGUgSUtFIFNBIG9yIHRoZSBDaGlsZCBTQXMu PC90Pg0KDQo8dD5XaGVuIHJla2V5aW5nLCBhIGZ1bGwgc2V0IG9mIHByZXZpb3VzbHkgbmVnb3Rp YXRlZCBwYXJhbWV0ZXJzDQphcmUgZXhjaGFuZ2VkLiBIb3dldmVyLCBtb3N0IG9mIHRoZXNlIHBh cmFtZXRlcnMgd2lsbCBiZSB0aGUgc2FtZSwNCmFuZCBzb21lIG9mIHRoZXNlIHBhcmFtZXRlcnMg TVVTVCBiZSB0aGUgc2FtZS48L3Q+DQoNCjx0PkZvciBleGFtcGxlLCB0aGUgVHJhZmZpYyBTZWxl Y3RvciAoVFMpIG5lZ290aWF0ZWQgZm9yIHRoZSBuZXcgQ2hpbGQNClNBIE1VU1QgY292ZXIgdGhl IFRyYWZmaWMgU2VsZWN0b3JzIG5lZ290aWF0ZWQgZm9yIHRoZSBvbGQgQ2hpbGQgU0EuIEFuZA0K aW4gcHJhY3RpY2FsbHkgYWxsIGNhc2VzLCBhIG5ldyBDaGlsZCBTQSB3b3VsZCBub3QgbmVlZCB0 byBjb3ZlciBtb3JlDQpUcmFmZmljIFNlbGVjdG9ycy4gSW4gdGhlIHJhcmUgY2FzZSB3aGVyZSB0 aGlzIHdvdWxkIGJlIG5lZWRlZCwgYSBuZXcNCkNoaWxkIFNBIGNvdWxkIGJlIG5lZ290aWF0aWVk IGluc3RlYWQgb2YgdGhlIGN1cnJlbnQgQ2hpbGQgU0EgYmVpbmcNCnJla2V5ZWQuIFNpbWlsYXJs eSwgSUtFdjIgc3RhdGVzIHRoYXQgdGhlIGNyeXB0b2dyYXBoaWMgcGFyYW1ldGVycw0KbmVnb3Rp YXRlZCBmb3IgcmVrZXlpbmcgU0hPVUxEIE5PVCBiZSBkaWZmZXJlbnQuIFRoaXMgbWVhbnMgdGhh dCB0aGUNCnNlY3VyaXR5IHByb3BlcnRpZXMgb2YgdGhlIElLRSBvciBDaGlsZCBTQSBpbiBwcmFj dGlzZSBkbyBub3QgY2hhbmdlDQpkdXJpbmcgYSB0eXBpY2FsIHJla2V5LjwvdD4NCg0KPHQ+VGhp cyBkb2N1bWVudCBzcGVjaWZpZXMgYSBtZXRob2QgdG8gb21pdCB0aGVzZSBwYXJhbWV0ZXJzIGFu ZCByZXBsYWNlDQp0aGVtIHdpdGggYSBzaW5nbGUgTm90aWZ5IE1lc3NhZ2UgZGVjbGFyaW5nIHRo YXQgYWxsIHRoZXNlIHBhcmFtZXRlcnMNCmFyZSBpZGVudGljYWwgdG8gdGhlIG9yaWdpbmFsbHkg bmVnb3RpYXRlZCBwYXJhbWV0ZXJzLjwvdD4NCg0KPHQ+Rm9yIHNlY3VyaXR5IGdhdGV3YXlzL2VQ REcgaW4gNEcgbmV0d29ya3Mgb3IgY1JBTi9DbG91ZCBnYXRld2F5cw0KaW4gNUcgbmV0d29ya3Ms IGdhdGV3YXlzIHR5cGljYWxseSBzdXBwb3J0IG1vcmUgdGhhbiAxMDAsMDAwIElLRS9JUFNFQw0K dHVubmVscy4gQXQgYW55IHBvaW50IGluIHRpbWUsIHRoZXJlIHdpbGwgYmUgaHVuZHJlZHMgb3Ig dGhvdXNhbmRzIG9mDQpJS0UgU0FzIGFuZCBDaGlsZCBTQXMgdGhhdCBhcmUgYmVpbmcgcmVrZXll ZC4gVGhpcyB0YWtlcyBhIGxhcmdlIGFtb3VudCBvZg0KYmFuZHdpZHRoIGFuZCBDUFUgcG93ZXIg YW5kIGFueSBwcm90b2NvbCBzaW1wbGlmaWNhdGlvbiBvciBiYW5kd2lkdGgNCnJlZHVjaW5nIHdv dWxkIHJlc3VsdCBpbiBhbiBzaWduaWZpY2FudCByZXNvdXJjZSBzYXZpbmcuPC90Pg0KDQo8dD5G b3IgSW50ZXJuZXQgb2YgVGhpbmdzIChJb1QpIGRldmljZXMgd2hpY2ggdXRpbGl6ZSBsb3cgcG93 ZXINCmNvbnN1bXB0aW9uIHRlY2hub2xvZ3ksIHJlZHVjaW5nIHRoZSBzaXplIG9mIHJla2V5IGV4 Y2hhbmdlIHJlZHVjZXMgaXRzDQpwb3dlciBjb25zdW1wdGlvbiwgYXMgc2VuZGluZyBieXRlcyBv dmVyIHRoZSBhaXIgaXMgdXN1YWxseSB0aGUgbW9zdA0KcG93ZXIgY29uc3VtaW5nIG9wZXJhdGlv biBvZiBzdWNoIGEgZGV2aWNlLiBSZWR1Y2luZyB0aGUgQ1BVIG9wZXJhdGlvbnMNCnJlcXVpcmVk IHRvIHZlcmlmeSB0aGUgcmVrZXkgZXhjaGFuZ2VzIHBhcmFtZXRlcnMgd2lsbCBhbHNvIHNhdmUg cG93ZXINCmFuZCBleHRlbmQgdGhlIGxpZmV0aW1lIGZvciB0aGVzZSBkZXZpY2VzLjwvdD4NCg0K PHQ+V2hlbiB1c2luZyBpZGVudGljYWwgcGFyYW1ldGVycyBkdXJpbmcgdGhlIElLRSBvciBDaGls ZCBTQSByZWtleSwNCnRoZSBTQSBhbmQgVFMgcGF5bG9hZHMgY2FuIGJlIG9taXRlZC4gRm9yIGFu IElLRSBTQSByZWtleSwgaW5zdGVhZCBvZg0KdGhlIChsYXJnZSkgU0EgcGF5bG9hZCwgb25seSBh IEtleSBFeGNoYW5nZSAoS0UpIHBheWxvYWQgYW5kIGEgbmV3DQpOb3RpZnkgVHlwZSBwYXlsb2Fk IHdpdGggdGhlIG5ldyBTUEkgaXMgcmVxdWlyZWQuICBGb3IgYSBDaGlsZCBTQQ0KcGF5bG9hZCwg aW5zdGVhZCBvZiB0aGUgU0Egb3IgVFMgcGF5bG9hZHMsIG9ubHkgYW4gb3B0aW9uYWwgTm9uY2Ug cGF5bG9hZA0KKHdoZW4gdXNpbmcgUEZTKSBhbmQgYSBuZXcgTm90aWZ5IFR5cGUgcGF5bG9hZCB3 aXRoIHRoZSBuZXcgU1BJIGlzIG5lZWRlZC4NClRoaXMgbWFrZXMgdGhlIHJla2V5IGV4Y2hhbmdl IHBhY2tldHMgbXVjaCBzbWFsbGVyIGFuZCB0aGUgcGVlcnMgZG8gbm90DQpuZWVkIHRvIHZlcmlm eSB0aGF0IHRoZSBTQSBvciBUUyBwYXJhbWV0ZXJzIGFyZSBjb21wYXRpYmxlIHdpdGggdGhlDQpv bGQgU0EuPC90Pg0KDQoNCjwvc2VjdGlvbj4NCjxzZWN0aW9uIGFuY2hvcj0iY29udmVudGlvbnMt dXNlZC1pbi10aGlzLWRvY3VtZW50IiB0aXRsZT0iQ29udmVudGlvbnMgVXNlZCBpbiBUaGlzIERv Y3VtZW50Ij4NCg0KPHNlY3Rpb24gYW5jaG9yPSJyZXF1aXJlbWVudHMtbGFuZ3VhZ2UiIHRpdGxl PSJSZXF1aXJlbWVudHMgTGFuZ3VhZ2UiPg0KDQo8dD5UaGUga2V5IHdvcmRzIOKAnE1VU1TigJ0s IOKAnE1VU1QgTk9U4oCdLCDigJxSRVFVSVJFROKAnSwg4oCcU0hBTEzigJ0sIOKAnFNIQUxMIE5P VOKAnSwNCuKAnFNIT1VMROKAnSwg4oCcU0hPVUxEIE5PVOKAnSwg4oCcUkVDT01NRU5ERUTigJ0s IOKAnE5PVCBSRUNPTU1FTkRFROKAnSwg4oCcTUFZ4oCdLCBhbmQg4oCcT1BUSU9OQUzigJ0gaW4g dGhpcyBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIEJDUA0K MTQgPHhyZWYgdGFyZ2V0PSJSRkMyMTE5Ii8+IDx4cmVmIHRhcmdldD0iUkZDODE3NCIvPiB3aGVu LCBhbmQgb25seSB3aGVuLCB0aGV5IGFwcGVhciBpbiBhbGwNCmNhcGl0YWxzLCBhcyBzaG93biBo ZXJlLjwvdD4NCg0KPC9zZWN0aW9uPg0KPC9zZWN0aW9uPg0KPHNlY3Rpb24gYW5jaG9yPSJuZWdv dGlhdGlvbiIgdGl0bGU9Ik5lZ290aWF0aW9uIG9mIFN1cHBvcnQgZm9yIE9QVElNSVpFRCBSRUtF WSI+DQoNCjx0PlRvIGluZGljYXRlIHN1cHBvcnQgZm9yIHRoZSBvcHRpbWl6ZWQgcmVrZXkgbmVn b3RpYXRpb24sIHRoZSBpbml0aWF0b3INCmluY2x1ZGVzIHRoZSBPUFRJTUlaRURfUkVLRVlfU1VQ UE9SVEVEIE5vdGlmeSBwYXlsb2FkIGluIHRoZSBJS0VfQVVUSA0KZXhjaGFuZ2UgcmVxdWVzdC4g QSByZXNwb25kZXIgdGhhdCBzdXBwb3J0cyB0aGUgb3B0aW1pemVkIHJla2V5IGV4Y2hhbmdlDQpp bmNsdWVzIHRoZSBPUFRJTUlaRURfUkVLRVlfU1VQUE9SVEVEIE5vdGlmeSBwYXlsb2FkIGluIGl0 cyByZXNwb25zZS4gTm90ZQ0KdGhhdCB0aGUgbm90aWZ5IGluZGljaWF0ZXMgc3VwcG9ydCBmb3Ig b3B0aW1pemVkIHJla2V5IGZvciBib3RoIElLRSBhbmQNCkNoaWxkIFNBcy48L3Q+DQoNCjx0Pldo ZW4gYSBwZWVyIHdpc2hlcyB0byByZWtleSBhbiBJS0UgU0Egb3IgQ2hpbGQgU0EsIGl0IE1BWSB1 c2UgdGhlDQpvcHRpbWl6ZWQgcmVrZXkgbWV0aG9kIGR1cmluZyB0aGUgQ1JFQVRFX0NISUxEX1NB IGV4Y2hhbmdlLiAgQSByZXNwb25kZXINCk1VU1QgYWNjZXB0IHRoYXQgdGhlIGluaXRpYXRvciB1 c2VzIGEgcmVndWxhciBvciBvcHRpbWl6ZWQgcmVleS48L3Q+DQoNCg0KPHQ+VGhlIGluaXRpYXRv ciBpbmRpY2F0ZXMgaXRzIHN1cHBvcnQgZm9yIG9wdGltaXppbmcgcGF5bG9hZHMNCmF0IHJla2V5 aW5nIElLRSBTQXMgYW5kIENoaWxkIFNBcyBieSBpbmNsdWRpbmcgYSBOb3RpZnkgcGF5bG9hZCBv Zg0KdHlwZSBNSU5JTUFMX1JFS0VZX1NVUFBPUlRFRCBpbiB0aGUgSUtFX0FVVEggcmVxdWVzdCBt ZXNzYWdlLiBCeQ0Kb2JzZXJ2aW5nIHRoZSBNSU5JTUFMX1JFS0VZX1NVUFBPUlRFRCBub3RpZmlj YXRpb24gaW4gdGhlIHJlY2VpdmVkDQptZXNzYWdlLCB0aGUgcmVzcG9uZGVyIGNhbiBkZWR1Y2Ug dGhlIGluaXRpYXRvcuKAmXMgc3VwcG9ydCBvZiB0aGlzDQpleHRlbnNpb24uIElmIHRoZSByZXNw b25kZXIgYWxzbyBzdXBwb3J0cyB0aGlzIGV4dGVuc2lvbiwgaXQNCmluY2x1ZGVzIHRoZSBNSU5J TUFMX1JFS0VZX1NVUFBPUlRFRCBub3RpZmljYXRpb24gaW4gdGhlDQpjb3JyZXNwb25kaW5nIHJl c3BvbnNlIG1lc3NhZ2UuIEFmdGVyIHJlY2VpdmluZyB0aGUgcmVzcG9uc2UNCm1lc3NhZ2UsIHRo ZSBpbml0aWF0b3IgY2FuIGFsc28ga25vdyB0aGUgc3VwcG9ydCBvZiB0aGlzIGV4dGVuc2lvbiBv Zg0KdGhlIHJlc3BvbmRlciBzaWRlLjwvdD4NCg0KPHQ+VGhlIElLRV9BVVRIIG1lc3NhZ2UgZXhj aGFuZ2UgaW4gdGhpcyBjYXNlIGlzIHNob3duIGJlbG93OjwvdD4NCg0KPGZpZ3VyZT48YXJ0d29y az48IVtDREFUQVsNCkluaXRpYXRvciAgICAgICAgICAgICAgICAgICAgICAgICBSZXNwb25kZXIN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpIRFIsIFNLIHtJRGksIFtDRVJULF0gW0NFUlRSRVEsXQ0KICAgIFtJRHIs XSBBVVRILCBTQWkyLCBUU2ksIFRTciwNCiAgICBOKE9QVElNSVpFRF9SRUtFWV9TVVBQT1JURUQp fSAtLT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwtLSBIRFIsIFNLIHtJRHIsIFtD RVJULF0gQVVUSCwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU0FyMiwg VFNpLCBUU3IsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE4oT1BUSU1J WkVEX1JFS0VZX1NVUFBPUlRFRCl9DQpdXT48L2FydHdvcms+PC9maWd1cmU+DQoNCjx0PklmIHRo ZSByZXNwb25kZXIgZG9lcyBub3Qgc3VwcG9ydCB0aGlzIGV4dGVuc2lvbiwgYXMgcGVyIHJlZ3Vs YXINCklLRXYyIHByb2Nlc3NpbmcsIGl0IE1VU1QgaWdub3JlIHRoZSB1bmtub3duIE5vdGlmeSBw YXlsb2FkLiBUaGUNCmluaXRpYXRvciB3aWxsIG5vdGljZSB0aGUgbGFjayBvZiB0aGUgT1BUSU1J WkVEX1JFS0VZX1NVUFBPUlRFRCBOb3RpZnkNCmluIHRoZSByZXBseSBhbmQgdGh1cyBrbm93IGl0 IGNhbm5vdCB1c2UgdGhlIG9wdGltaXplZCByZWtleSBtZXRob2QuPC90Pg0KDQo8dD5UaGUgSUtF X0FVVEggbWVzc2FnZSBleGNoYW5nZSBpbiB0aGlzIGNhc2UgaXMgc2hvd24gYmVsb3c6PC90Pg0K DQo8L3NlY3Rpb24+DQo8c2VjdGlvbiBhbmNob3I9InBheWxvYWQtb3B0aW1pemF0aW9uLWlrZSIg dGl0bGU9Ik9wdGltaXplZCBSZWtleSBvZiB0aGUgSUtFIFNBIj4NCg0KPHQ+VGhlIGluaXRpYXRv ciBvZiBhbiBvcHRpbWl6ZWQgcmVrZXkgcmVxdWVzdCBzZW5kcyBhIENSRUFURV9DSElMRF9TQQ0K cGF5bG9hZCB3aXRoIHRoZSBPUFRJTUlaRURfUkVLRVkgbm90aWZ5IHBheWxvYWQgY29udGFpbmlu ZyB0aGUgbmV3DQpTZWN1cml0eSBQYXJhbWV0ZXIgSW5kZXggKFNQSSkgZm9yIHRoZSBuZXcgSUtF IFNBLiAgSXQgb21pdHMgdGhlIFNBDQpwYXlsb2FkLjwvdD4NCg0KPHQ+VGhlIHJlc3BvbmRlciBv ZiBhbiBvcHRpbWl6ZWQgcmVrZXkgcmVxdWVzdCBwZXJmb3JtcyB0aGUgc2FtZSBwcm9jZXNzLiBJ dA0KaW5jbHVkZXMgdGhlIE9QVElNSVpFRF9SRUtFWSBub3RpZnkgd2l0aCBpdHMgbmV3IElLRSBT UEkgYW5kIG9taXRzIHRoZSBTQQ0KcGF5bG9hZC48L3Q+DQoNCjx0PkJvdGggcGFydGllcyBzZW5k IE5vbmNlIGFuZCBLRSBwYXlsb2FkcyBqdXN0IGFzIHRoZXkgd291bGQgZG8gZm9yIGEgcmVndWxh cg0KSUtFIFNBIHJla2V5LjwvdD4NCg0KPHQ+VGhlIENSRUFURV9DSElMRF9TQSBtZXNzYWdlIGV4 Y2hhbmdlIGluIHRoaXMgY2FzZSBpcyBzaG93biBiZWxvdzo8L3Q+DQoNCjxmaWd1cmU+PGFydHdv cms+PCFbQ0RBVEFbDQpJbml0aWF0b3IgICAgICAgICAgICAgICAgICAgICAgICAgUmVzcG9uZGVy DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KSERSLCBTSyB7TihPUFRJTUlaRURfUkVLRVkpLA0KICAgIE5pLCBLRWl9 IC0tPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC0tIEhEUiwgU0sge04oT1BUSU1J WkVEX1JFS0VZKSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTnIsIEtF cn0NCl1dPjwvYXJ0d29yaz48L2ZpZ3VyZT4NCg0KPC9zZWN0aW9uPg0KPHNlY3Rpb24gYW5jaG9y PSJwYXlsb2FkLW9wdGltaXphdGlvbi1jaGlsZCIgdGl0bGU9Ik9wdGltaXplZCBSZWtleSBvZiBD aGlsZCBTQXMiPg0KDQo8dD5UaGUgaW5pdGlhdG9yIG9mIGFuIG9wdGltaXplZCByZWtleSByZXF1 ZXN0IHNlbmRzIGEgQ1JFQVRFX0NISUxEX1NBDQpwYXlsb2FkIHdpdGggdGhlIE9QVElNSVpFRF9S RUtFWSBub3RpZnkgcGF5bG9hZCBjb250YWluaW5nIHRoZSBuZXcNClNlY3VyaXR5IFBhcmFtZXRl ciBJbmRleCAoU1BJKSBmb3IgdGhlIG5ldyBDaGlsZCBTQS4gSXQgb21pdHMgdGhlIFNBDQpwYXls b2FkLiBJZiB0aGUgY3VycmVudCBDaGlsZCBTQSB3YXMgbmVnb3RpYXRlZCB3aXRoIFBlcmZlY3Qg Rm9yd2FyZA0KU2VjcmVjeSAoUEZTKSwgYSBLRWkgcGF5bG9hZCBNVVNUIGJlIGluY2x1ZGVkIGFz IHdlbGwuIElmIG5vIFBGUw0Kd2FzIG5lZ290aWF0ZWQgZm9yIHRoZSBjdXJyZW50IENoaWxkIFNB LCBhIEtFaSBwYXlsb2FkIE1VU1QgTk9UIGJlDQppbmNsdWRlZC48L3Q+DQoNCjx0PlRoZSByZXNw b25kZXIgb2YgYW4gb3B0aW1pemVkIHJla2V5IHJlcXVlc3QgcGVyZm9ybXMgdGhlIHNhbWUNCnBy b2Nlc3MuIEl0IGluY2x1ZGVzIHRoZSBPUFRJTUlaRURfUkVLRVkgbm90aWZ5IHdpdGggaXRzIG5l dyBJS0UgU1BJDQphbmQgb21pdHMgdGhlIFNBIGFuZCBUUyBwYXlsb2Fkcy4gRGVwZW5kaW5nIG9u IHRoZSBQRlMgbmVnb3RpYXRpb24gb2YNCnRoZSBjdXJyZW50IENoaWxkIFNBLCB0aGUgcmVzcG9u ZGVyIGluY2x1ZGVzIGEgS0VyIHBheWxvYWQuPC90Pg0KDQo8dD5Cb3RoIHBhcnRpZXMgc2VuZCBO b25jZSBwYXlsb2FkcyBqdXN0IGFzIHRoZXkgd291bGQgZG8gZm9yIGEgcmVndWxhcg0KQ2hpbGQg U0EgcmVrZXkuPC90Pg0KDQo8dD5Vc2luZyB0aGUgcmVjZWl2ZWQgb2xkIFNQSSBmcm9tIHRoZSBS RUtFWV9TQSBwYXlsb2FkIGFuZCB0aGUgbmV3IFNQSQ0KcmVjZWl2ZWQgZnJvbSB0aGUgT1BUSU1J WkVEX1JFS0VZIHBheWxvYWQsIGJvdGggcGFydGllcyBjYW4gcGVyZm9ybSB0aGUNCkNoaWxkIFNB IHJla2V5IG9wZXJhdGlvbi48L3Q+DQoNCjx0PlRoZSBDUkVBVEVfQ0hJTERfU0EgbWVzc2FnZSBl eGNoYW5nZSBpbiB0aGlzIGNhc2UgaXMgc2hvd24gYmVsb3c6PC90Pg0KDQo8ZmlndXJlPjxhcnR3 b3JrPjwhW0NEQVRBWw0KSW5pdGlhdG9yICAgICAgICAgICAgICAgICAgICAgICAgIFJlc3BvbmRl cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCkhEUiwgU0sge04oUkVLRVlfU0EpLCBOKE9QVElNSVpFRF9SRUtFWSks DQogICAgTmksIFtLRWksXX0gLS0+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8LS0g SERSLCBTSyB7TihPUFRJTUlaRURfUkVLRVkpLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBOciwgW0tFcixdfQ0KXV0+PC9hcnR3b3JrPjwvZmlndXJlPg0KPC9zZWN0aW9u Pg0KDQo8c2VjdGlvbiBhbmNob3I9InBheWxvYWQtZm9ybWF0cyIgdGl0bGU9IlBheWxvYWQgRm9y bWF0cyI+DQoNCjxzZWN0aW9uIGFuY2hvcj0ic3VwcG9ydGVkLW5vdGlmeSIgdGl0bGU9Ik9QVElN SVpFRF9SRUtFWV9TVVBQT1JURUQgTm90aWZ5Ij4NCg0KPHQ+VGhlIE9QVElNSVpFRF9SRUtFWV9T VVBQT1JURUQgTm90aWZ5IE1lc3NhZ2UgdHlwZSBub3RpZmljYXRpb24gaXMgdXNlZCBieSB0aGUg aW5pdGlhdG9yIGFuZA0KcmVzcG9uZGVyIHRvIGluZGljYXRlIHRoZWlyIHN1cHBvcnQgZm9yIHRo ZSBvcHRpbWl6ZWQgcmVrZXkgbmVnb3RhdGlvbi48L3Q+DQoNCjxmaWd1cmU+PGFydHdvcms+PCFb Q0RBVEFbDQogICAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAg ICAgICAgICAgICAgMw0KIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAw IDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCnwgTmV4dCBQYXlsb2FkICB8Q3wgIFJF U0VSVkVEICAgfCAgICAgICAgIFBheWxvYWQgTGVuZ3RoICAgICAgICB8DQorLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KfFBy b3RvY29sIElEKD0wKXwgU1BJIFNpemUgKD0wKSB8ICAgICAgTm90aWZ5IE1lc3NhZ2UgVHlwZSAg ICAgIHwNCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rDQpdXT48L2FydHdvcms+PC9maWd1cmU+DQoNCjx0PjxsaXN0IHN0eWxl PSJzeW1ib2xzIj4NCiAgPHQ+UHJvdG9jb2wgSUQgKDEgb2N0ZXQpIC0gTVVTVCBiZSAwLjwvdD4N CiAgPHQ+U1BJIFNpemUgKDEgb2N0ZXQpIC0gTVVTVCBiZSAwLCBtZWFuaW5nIG5vIFNQSSBpcyBw cmVzZW50LjwvdD4NCiAgPHQ+Tm90aWZ5IE1lc3NhZ2UgVHlwZSAoMiBvY3RldHMpIC0gTVVTVCBi ZSB0aGUgdmFsdWUgW1RCRDFdLjwvdD4NCjwvbGlzdD48L3Q+DQoNCjx0PlRoaXMgTm90aWZ5IE1l c3NhZ2UgdHlwZSBjb250YWlucyBubyBkYXRhLjwvdD4NCg0KPC9zZWN0aW9uPg0KPHNlY3Rpb24g YW5jaG9yPSJvcHRpbWl6ZWQtcmVrZXkiIHRpdGxlPSJPUFRJTUlaRURfUkVLRVkgTm90aWZ5Ij4N Cg0KPHQ+VGhlIE9QVElNSVpFRF9SRUtFWSBOb3RpZnkgTWVzc2FnZSB0eXBlIGlzIHVzZWQgdG8g cGVyZm9ybSBhbiBvcHRpbWl6ZWQNCklLRSBTQSBvciBDaGlsZCBTQSByZWtleS48L3Q+DQoNCjxm aWd1cmU+PGFydHdvcms+PCFbQ0RBVEFbDQogMCAgICAgICAgICAgICAgICAgMSAgICAgICAgICAg ICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCiAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCistKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQp8IE5leHQg UGF5bG9hZCAgfEN8ICBSRVNFUlZFRCAgIHwgICAgICAgICBQYXlsb2FkIExlbmd0aCAgICAgICAg fA0KKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsNCnxQcm90b2NvbCBJRCAgICB8IFNQSSBTaXplICg9OCkgfCAgICAgIE5vdGlm eSBNZXNzYWdlIFR5cGUgICAgICB8DQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KfCAgICAgICAgICAgICAgICBTZWN1cml0 eSBQYXJhbWV0ZXIgSW5kZXggKFNQSSkgICAgICAgICAgICAgICAgIHwNCnwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQorLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKw0KXV0+PC9hcnR3b3JrPjwvZmlndXJlPg0KDQo8dD48bGlzdCBzdHlsZT0ic3ltYm9scyI+ DQogIDx0PlByb3RvY29sIElEICgxIG9jdGV0KSAtIE1VU1QgYmUgMS48L3Q+DQogIDx0PlNQSSBT aXplICgxIG9jdGV0KSAtIE1VU1QgYmUgOCB3aGVuIHJla2V5aW5nIGFuIElLRSBTQXMuIE1VU1Qg YmUgNCB3aGVuIHJla2V5aW5nIGEgQ2hpbGQgU0EuPC90Pg0KICA8dD5Ob3RpZnkgTWVzc2FnZSBU eXBlICgyIG9jdGV0cykgLSBNVVNUIGJlIHNldCB0byB0aGUgdmFsdWUgW1RCRDJdLjwvdD4NCiAg PHQ+U1BJICg0IG9jdGV0cyBvciA4IG9jdGV0cykgLSBTZWN1cml0eSBQYXJhbWV0ZXIgSW5kZXgu IFRoZSBwZWVyJ3MgbmV3IFNQSS48L3Q+DQo8L2xpc3Q+PC90Pg0KDQo8L3NlY3Rpb24+DQo8L3Nl Y3Rpb24+DQo8c2VjdGlvbiBhbmNob3I9ImlhbmEtY29uc2lkZXJhdGlvbnMiIHRpdGxlPSJJQU5B IENvbnNpZGVyYXRpb25zIj4NCg0KPHQ+VGhpcyBkb2N1bWVudCBkZWZpbmVzIHR3byBuZXcgTm90 aWZ5IE1lc3NhZ2UgVHlwZXMgaW4gdGhlIOKAnElLRXYyDQpOb3RpZnkgTWVzc2FnZSBUeXBlcyAt IFN0YXR1cyBUeXBlc+KAnSByZWdpc3RyeS4gSUFOQSBpcyByZXF1ZXN0ZWQgdG8NCmFzc2lnbiBj b2RlcG9pbnRzIGluIHRoaXMgcmVnaXN0cnkuPC90Pg0KDQo8ZmlndXJlPjxhcnR3b3JrPjwhW0NE QVRBWw0KTk9USUZZIG1lc3NhZ2VzOiBzdGF0dXMgdHlwZXMgICAgICAgICAgICBWYWx1ZQ0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K T1BUSU1JWkVEX1JFS0VZX1NVUFBPUlRFRCAgICAgICAgICAgICAgICAgIFRCRDENCk9QVElNSVpF RF9SRUtFWSAgICAgICAgICAgICAgICAgICAgICAgICAgICBUQkQyDQpdXT48L2FydHdvcms+PC9m aWd1cmU+DQoNCjwvc2VjdGlvbj4NCjxzZWN0aW9uIGFuY2hvcj0ib3BlcmF0aW9uYWwtY29uc2lk ZXJhdGlvbnMiIHRpdGxlPSJPcGVyYXRpb25hbCBDb25zaWRlcmF0aW9ucyI+DQoNCjx0PlNvbWUg aW1wbGVtZW50YXRpb25zIGFsbG93IHNlbmRpbmcgcmVrZXkgbWVzc2FnZXMgd2l0aCBhIGRpZmZl cmVudA0Kc2V0IG9mIFRyYWZmaWMgU2VsZWN0b3JzIG9yIGNyeXB0b2dyYXBoaWMgcGFyYW1ldGVy cyBpbiByZXNwb25zZSB0byBhDQpjb25maWd1cmF0aW9uIHVwZGF0ZS4gSUtFdjIgc3RhdGVzIHRo aXMgU0hPVUxEIE5PVCBiZSBkb25lLiAgV2hldGhlciBvcg0Kbm90IG9wdGltaXplZCByZWtleWlu ZyBpcyB1c2VkLCBhIGNvbmZpZ3VyYXRpb24gY2hhbmdlIHRoYXQgY2hhbmdlcyB0aGUNClRyYWZm aWMgU2VsZWN0b3JzIG9yIGNyeXB0b2dyYXBoaWMgcGFyYW1ldGVycyBNVVNUIE5PVCB1c2UgdGhl IG9wdGltaXplZA0KcmVrZXkgbWV0aG9kLiBJdCBTSE9VTEQgYWxzbyBub3QgdXNlIGEgcmVndWxh ciByZWtleSBtZXRob2QgYnV0IGluc3RlYWQNCnN0YXJ0IGFuIGVudGlyZSBuZXcgSUtFIGFuZCBD aGlsZCBTQSBuZWdvdGlhdGlvbiB3aXRoIHRoZSBuZXcgcGFyYW1ldGVycy48L3Q+DQo8L3NlY3Rp b24+DQoNCjxzZWN0aW9uIGFuY2hvcj0ic2VjdXJpdHktY29uc2lkZXJhdGlvbnMiIHRpdGxlPSJT ZWN1cml0eSBDb25zaWRlcmF0aW9ucyI+DQo8dD5UaGUgb3B0aW1pemVkIHJla2V5IHJlbW92ZXMg c2VuZGluZyB1bm5lY2Nlc3NhcnkgbmV3IHBhcmFtZXRlcnMgdGhhdA0Kb3JpZ2luYWxseSB3b3Vs ZCBoYXZlIHRvIGJlIHZhbGlkYXRlZCBhZ2FpbnN0IHRoZSBvcmlnaW5hbCBwYXJhbWV0ZXJzLiBJ bg0KdGhhdCBzZW5zZSwgdGhpcyBvcHRpbWFsaXphdGlvbiBlbmhhbmNlcyB0aGUgc2VjdXJpdHkg b2YgdGhlIHJla2V5DQpwcm9jZXNzLjwvdD4NCjwvc2VjdGlvbj4NCg0KPHNlY3Rpb24gYW5jaG9y PSJhY2tub3dsZWRnbWVudHMiIHRpdGxlPSJBY2tub3dsZWRnbWVudHMiPg0KPHQ+U3BlY2lhbCB0 aGFua3MgZ28gdG8gUGF1bCBXb3V0ZXJzLCBWYWxlcnkgU215c2xvdiwgYW5kIEFudG9ueSBBbnRv bnkuPC90Pg0KPC9zZWN0aW9uPg0KDQogIDwvbWlkZGxlPg0KICA8YmFjaz4NCiAgICA8cmVmZXJl bmNlcyB0aXRsZT0nTm9ybWF0aXZlIFJlZmVyZW5jZXMnPg0KDQo8cmVmZXJlbmNlICBhbmNob3I9 IlJGQzIxMTkiIHRhcmdldD0naHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmMyMTE5 Jz4NCjxmcm9udD4NCjx0aXRsZT5LZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRl IFJlcXVpcmVtZW50IExldmVsczwvdGl0bGU+DQo8YXV0aG9yIGluaXRpYWxzPSdTLicgc3VybmFt ZT0nQnJhZG5lcicgZnVsbG5hbWU9J1MuIEJyYWRuZXInPjxvcmdhbml6YXRpb24gLz48L2F1dGhv cj4NCjxkYXRlIHllYXI9JzE5OTcnIG1vbnRoPSdNYXJjaCcgLz4NCjxhYnN0cmFjdD48dD5JbiBt YW55IHN0YW5kYXJkcyB0cmFjayBkb2N1bWVudHMgc2V2ZXJhbCB3b3JkcyBhcmUgdXNlZCB0byBz aWduaWZ5IHRoZSByZXF1aXJlbWVudHMgaW4gdGhlIHNwZWNpZmljYXRpb24uICBUaGVzZSB3b3Jk cyBhcmUgb2Z0ZW4gY2FwaXRhbGl6ZWQuIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGVzZSB3b3Jk cyBhcyB0aGV5IHNob3VsZCBiZSBpbnRlcnByZXRlZCBpbiBJRVRGIGRvY3VtZW50cy4gIFRoaXMg ZG9jdW1lbnQgc3BlY2lmaWVzIGFuIEludGVybmV0IEJlc3QgQ3VycmVudCBQcmFjdGljZXMgZm9y IHRoZSBJbnRlcm5ldCBDb21tdW5pdHksIGFuZCByZXF1ZXN0cyBkaXNjdXNzaW9uIGFuZCBzdWdn ZXN0aW9ucyBmb3IgaW1wcm92ZW1lbnRzLjwvdD48L2Fic3RyYWN0Pg0KPC9mcm9udD4NCjxzZXJp ZXNJbmZvIG5hbWU9J0JDUCcgdmFsdWU9JzE0Jy8+DQo8c2VyaWVzSW5mbyBuYW1lPSdSRkMnIHZh bHVlPScyMTE5Jy8+DQo8c2VyaWVzSW5mbyBuYW1lPSdET0knIHZhbHVlPScxMC4xNzQ4Ny9SRkMy MTE5Jy8+DQo8L3JlZmVyZW5jZT4NCg0KDQoNCjxyZWZlcmVuY2UgIGFuY2hvcj0iUkZDODE3NCIg dGFyZ2V0PSdodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzgxNzQnPg0KPGZyb250 Pg0KPHRpdGxlPkFtYmlndWl0eSBvZiBVcHBlcmNhc2UgdnMgTG93ZXJjYXNlIGluIFJGQyAyMTE5 IEtleSBXb3JkczwvdGl0bGU+DQo8YXV0aG9yIGluaXRpYWxzPSdCLicgc3VybmFtZT0nTGVpYmEn IGZ1bGxuYW1lPSdCLiBMZWliYSc+PG9yZ2FuaXphdGlvbiAvPjwvYXV0aG9yPg0KPGRhdGUgeWVh cj0nMjAxNycgbW9udGg9J01heScgLz4NCjxhYnN0cmFjdD48dD5SRkMgMjExOSBzcGVjaWZpZXMg Y29tbW9uIGtleSB3b3JkcyB0aGF0IG1heSBiZSB1c2VkIGluIHByb3RvY29sICBzcGVjaWZpY2F0 aW9ucy4gIFRoaXMgZG9jdW1lbnQgYWltcyB0byByZWR1Y2UgdGhlIGFtYmlndWl0eSBieSBjbGFy aWZ5aW5nIHRoYXQgb25seSBVUFBFUkNBU0UgdXNhZ2Ugb2YgdGhlIGtleSB3b3JkcyBoYXZlIHRo ZSAgZGVmaW5lZCBzcGVjaWFsIG1lYW5pbmdzLjwvdD48L2Fic3RyYWN0Pg0KPC9mcm9udD4NCjxz ZXJpZXNJbmZvIG5hbWU9J0JDUCcgdmFsdWU9JzE0Jy8+DQo8c2VyaWVzSW5mbyBuYW1lPSdSRkMn IHZhbHVlPSc4MTc0Jy8+DQo8c2VyaWVzSW5mbyBuYW1lPSdET0knIHZhbHVlPScxMC4xNzQ4Ny9S RkM4MTc0Jy8+DQo8L3JlZmVyZW5jZT4NCg0KDQoNCjxyZWZlcmVuY2UgIGFuY2hvcj0iUkZDNzI5 NiIgdGFyZ2V0PSdodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzcyOTYnPg0KPGZy b250Pg0KPHRpdGxlPkludGVybmV0IEtleSBFeGNoYW5nZSBQcm90b2NvbCBWZXJzaW9uIDIgKElL RXYyKTwvdGl0bGU+DQo8YXV0aG9yIGluaXRpYWxzPSdDLicgc3VybmFtZT0nS2F1Zm1hbicgZnVs bG5hbWU9J0MuIEthdWZtYW4nPjxvcmdhbml6YXRpb24gLz48L2F1dGhvcj4NCjxhdXRob3IgaW5p dGlhbHM9J1AuJyBzdXJuYW1lPSdIb2ZmbWFuJyBmdWxsbmFtZT0nUC4gSG9mZm1hbic+PG9yZ2Fu aXphdGlvbiAvPjwvYXV0aG9yPg0KPGF1dGhvciBpbml0aWFscz0nWS4nIHN1cm5hbWU9J05pcicg ZnVsbG5hbWU9J1kuIE5pcic+PG9yZ2FuaXphdGlvbiAvPjwvYXV0aG9yPg0KPGF1dGhvciBpbml0 aWFscz0nUC4nIHN1cm5hbWU9J0Vyb25lbicgZnVsbG5hbWU9J1AuIEVyb25lbic+PG9yZ2FuaXph dGlvbiAvPjwvYXV0aG9yPg0KPGF1dGhvciBpbml0aWFscz0nVC4nIHN1cm5hbWU9J0tpdmluZW4n IGZ1bGxuYW1lPSdULiBLaXZpbmVuJz48b3JnYW5pemF0aW9uIC8+PC9hdXRob3I+DQo8ZGF0ZSB5 ZWFyPScyMDE0JyBtb250aD0nT2N0b2JlcicgLz4NCjxhYnN0cmFjdD48dD5UaGlzIGRvY3VtZW50 IGRlc2NyaWJlcyB2ZXJzaW9uIDIgb2YgdGhlIEludGVybmV0IEtleSBFeGNoYW5nZSAoSUtFKSBw cm90b2NvbC4gIElLRSBpcyBhIGNvbXBvbmVudCBvZiBJUHNlYyB1c2VkIGZvciBwZXJmb3JtaW5n IG11dHVhbCBhdXRoZW50aWNhdGlvbiBhbmQgZXN0YWJsaXNoaW5nIGFuZCBtYWludGFpbmluZyBT ZWN1cml0eSBBc3NvY2lhdGlvbnMgKFNBcykuICBUaGlzIGRvY3VtZW50IG9ic29sZXRlcyBSRkMg NTk5NiwgYW5kIGluY2x1ZGVzIGFsbCBvZiB0aGUgZXJyYXRhIGZvciBpdC4gIEl0IGFkdmFuY2Vz IElLRXYyIHRvIGJlIGFuIEludGVybmV0IFN0YW5kYXJkLjwvdD48L2Fic3RyYWN0Pg0KPC9mcm9u dD4NCjxzZXJpZXNJbmZvIG5hbWU9J1NURCcgdmFsdWU9Jzc5Jy8+DQo8c2VyaWVzSW5mbyBuYW1l PSdSRkMnIHZhbHVlPSc3Mjk2Jy8+DQo8c2VyaWVzSW5mbyBuYW1lPSdET0knIHZhbHVlPScxMC4x NzQ4Ny9SRkM3Mjk2Jy8+DQo8L3JlZmVyZW5jZT4NCg0KDQoNCg0KICAgIDwvcmVmZXJlbmNlcz4N Cg0KDQoNCg0KDQogIDwvYmFjaz4NCg0KPCEtLSAjI21hcmtkb3duLXNvdXJjZToNCkg0c0lBQzJJ NG1BQUErMWI3VzRiU1hiOVQ0RHZVUEVBTzlLRzVFZ2EyK01STm91aEpYbk10U1Vyb3J6Tw0KWkha Z0ZObEZzcUptTjdlcm1oeXU3VVZlSTYrWEo4bTV0NnE2bTgybUpIc01Jd21XQml5eVdSLzM4OXhU DQpIK3gydSsyVzFUWld4Mkx3NG14NUpGNHRyRTRUR1l0aC8zZlhRM0VwMTNFcUl5TjBJazVtT283 RTJhL2oNCm1VeW1xdDJTbzFHbWxsc2RYYlBON3UxV2xJNFRPY2MwVVNZbnRuc2o1d3RwZFZjdmpC clBWVmZmcU9WUg0KMThpdU5kMkY3OVJORjdaNzhLamRHa3VycG1tMlBoYkdSdTFXdTZVWDJiR3dX VzdzMGNIQjl3ZEhrQ1ZUDQo4bGdNMVRqUHRGMjNXNnMwdTVsbWFiNkFlSmZEczVQek0vRUdqM1F5 RlQvUzQzYnJScTNSS01MM2lWVloNCm9tejNsQ1NqNFkyVlNmUld4bW1pZUJyb3V0REg3WllRTmgw Zmk3VXk5TjZrbWMzVXhKUVAxdlBLWjhpVQ0KMjFtYW9WOFgxc1BqWVUrOGNHcFRhMmVOSVdaU2Fs SDlJczJteCtKNUxsZEtpMnMxbmlWcG5FNjFteUtZDQozSDFOVDlSYzZoaUdjZU40cy80dzQrOTc0 M1RPZ2tGT1pZL0ZxVjZ1cFpuaGd4OFkvc2x1T3VMTlRGczENCjBTcU9xUFU0alNEWTE0OGVIeHc4 ZnZ3MVA0RkpqOFZUZUIwMnlSUTl5dFFVM2o2RzNGa2lyYnlScm1lZQ0KV0hMVElJbTBMUFIrMDhN OFNhbnpHeWptSDN5U3Jpc2R4MXJPZXd1WjRJc2R1aDRlSElwaE9yRXJSSWJvDQpMMVdTcTQ3NEtV ZGpLelVzZ1haNmJFdDlIendvTmIyUXlYOGdVcXA2L2tsRGU1TnZhSWxBVDBvdHozdmkNCjZVeG0w czVLVGM5VmhIZ1VRL3lyZk1kS24wdklwRE14WEJ1cjVrWmNMcTE0YWFPcTRyNUpSZk9SRzZRMw0K NTNGL21Mc0dkZFhQWmJLR2xteFE5bkN6bHAvc1QyaDZNbE5KVlUwZFUyYUZwNndnVzBlY3B5TWRx NnBXDQpKK2NuSnhXVnh1Z3pkLzEvR0ZPWE9mZW82L1R0a2ZpM0hQN081eXBCQUJrcmh2eE54MzFv OE9maHdjSEINCm8yK3IraXBkOTJybDBVbk5xKzFXa21aejVOSlNjZVpmUFRzNU9qejhQcngvY3Zq ZHcvRCt1NlB2SHg4eg0KTENXVFNoLzNyOXZ0UW5WSUo4ZU1MZGN6YlFUQWtCU3hJbEptbk9tUk1r S0t1UUpjUkFKRFFMNG9INU5GDQo3VXdKby8rbVJEcWg5KzFXQUN2eFFxMExLQlpMbFJrb0pJN0VI b1B4dmxEK0t3eHNoZFZ6SGlGVEFEM1cNCkY2MkEwUGd5aVFxOE5tSzBScE41dXFTWkljVmNNbDZt QWRneHdyQXZmaWV1aDhCRGo5RTljUlZrRFhLNg0KY2xBS1FQb3Fvek01aWhWckY2Y3JESkN1VkFa ZkpTYWY4d1JpSkMxMFd3ditSa1hvdE5SamhSa0dWc2pZDQpwR0ttNG9VQkJBdTVUSFVFWEcrM0pw bWNraUVsajFCTVBsZkdTTXpkQ3g2WTZ5aWlNR3kzdmlLOHoxTEkNClRGMmNSNVJvTnVzaVN3SDRh ZHhnWDdOUVl3M0lqSkFTN2RiUFBncCtJV1Z6dzAvWmQ0UExvaWFoNnlYZQ0KN3d1WmpRbHZ4emJQ bkQzWXNZczhXNlFHNWlJcmh5NTlZOUt4ZHNydERmdjdZb0g4UjV4QUhKR2dKRnIvDQpIZHpveWcx TW9hbGFSZ0tlTG56UUU2UmpvVTFPMDd3K3ZSVFNzSkNJemNRc1VNMWdUNGlqclNrTTJCR3INCm1R YUtzRytYTWdNMGkwbVd6a1dNQnVnc1lmUkVpVm1lUk9TeTBkb1Nkc05GUnNGbWlKa2JIYWY4bEYz Ug0KSDQ5UmNqbXdVMUVZcmVQQ1hJMHpPQUJ5ZXhNaUdtSHNiOWhxSEo1bWx1WlVva2JLTlVpVGVN MEdsQ0xXDQpjMDFhQXoyUXhwd3RGUE1VM3BpSk5JZTl5M1l3VnRFd0F0ejFVQUtWODFpc0p5cmtD N1JEd0t0ZkZ6b2oNCngyVGtYVGxLYzJSVTJtNjU1MDc0aFNLWGpOR0JjNHlmb1N2bUJraUJUb3hp YldhWVAxRXIveHdZQzY5eg0KMzFpT1E0S0xOQ2E5RkZ2ckdXWTBJUlNtOE9wS3JzMDM2dkwwUndx dmh6OWlORXM4eDZYeCtLcC84YzFKDQpuT1ljZkk5K0JJRDVyMW5FTlpkTllmSUZlVnJNZ2Z2T2Y4 REpEcUF5MlByc1JOZzhTVlNNeEJ0Q1M0NHUNClpCeThPWVd5Wkc1eTdab2tTOG04TXlRcm9HSXRS a1Vjc0swQVpqbXhFb3JvWFlBREFlQVY5QS9JUkpFSw0KSTVOeERFWkREaGFPZ3QvUmVhVWpPK3Nn RDhZM0NKYk45S2V4V1MvNEc4QmhLTTdndURUUEdFWmdUamE0DQpVUUZhMkRDRzJ3T2I1czZCVU1P azhkSUZvUFpZNGJFWTFEQ05jNTRzSUxkUDlRcW85d3FZcDNBaDRFSzANClR2S1lHaFk0QTNlakNT Z0ZZQ0c5M2c4U3VYUnJ0ekJIclA5R3M4YU1rOXRvYVFOYldqZHJ0bEZDWXBWTQ0KN2N6ajR6ZkIv b1hWaTNRbnFwMkFTeTRWZHlzTVhwMjVKL3JXSlN5UWlOT3NBOGhnMDVHeU1GSG9qaEsrDQpnQ0lZ M3p0RWNZbGg2UEQxZzUydmszR2NSeXBpdzUybnhoYldpTkxrdi8venZ5ejZxd24wUjlwNFpCNW4N CjY0Vk5wNWxjd0Y0SWFpUTFBWlA2YXc0SHhHdU05SFJOVWVRTVFINklsaEp4TWxVaE5TbFlzRUFK ZFN5NA0KZmk0alZWUTh3SVJUdFY1QVJXTTRvMUxCZURuRHBjMDVKanVVUUVBcG4vbVhBNEJvbkN1 S2pFUXA2TXc2DQpZZTFpbldEVXlvMjlNVFQwR2FaK2tBdWcvbVJkR05EaE0vd0RXcHNZUHdpUFhN N21kSU5uaUhLZ2xWWG8NCjZBRm4yeFRzQm1neWxxWlI2VTdvVjdjZG1XMk9Rb0dVbUhBOFprN1J3 bXNZck1seGJMZjZiTzFXWWRmTw0KSFQ2cnppc3EweUthYjUyWHgrdWZ2Q1RyVGZRMHo5aGxQY2NT VHRKa1NkVVVnUzllKzRyT1NYM3EwNXliDQpmUVg2ODljY1pZQ2VHUEVTMCtWeXFnS3RvRkpBaTB3 akhweS9IbDQvNkxpLzR1SVZ2Nzg2KzlmWGc2dXoNClUzby9mTjUvK2JKNDQxcTBXL2owNnZWTDM0 RGVsVjFQWHAyZm4xMmN1dDU0S21xUHp2cy80UStwK09EVg0KNWZYZzFVWC81WU10ck9MOFF3aU9L QXNCVFVnMExxTm1FOStlbm9CckhUNFU3OTc5aytmQkh6NzREMFNFDQo4V0dGK3VsbTQzaDNIN25z eU1WQ3lZeEdrWEZNQUxQUUZrRFJvVWxRMFZlSklJOTVxMThHam5LcUVNK3gNCkthQVUxWVpoRDBp eTFKQ3RaRE9SYStscTRFWWFCQzVPYkRXekxxNmZxZ2xWaU53VXlFQTU1U1BJcGF3bg0KYnNRNjlI d1JxN0xBckdZRWI2NkNHZ0s5bVdRK2VwT2tLMWZMQWhkd3VGOXBDb2FocVNKYVgwWjhHU2JhDQpt MW9Dak1pWG8wbzBiOEd6NEFRR2hJSWhRQ21heHhmZVBNbFFqcWNKZEFnc204ZWliR0NCVUZpSkJ5 bUsNCmFhZjNCRmJMYWZISGZHNUdia293bVJOaW9qUEFNSUJpUWFrRUZRUGJkREJWaUQvaHNRQnlG UU5DSHJ0Uw0Kbms2QmdUaHl4QndVbHVlQXcwTlBvTWVWaENkQUpSakFFck1SYUl1SEZjVHRUNnp5 RExwQ2lKMFNPdEgwDQpHYllnb0FoMjVhL3FwaTB3aFJaeHppVXNDVU9Uc3lMbmNRZW1Id2VvTHZr MzdCQk1NcUZhN09maTBoZkENCkN0RnhlL2tnUzFQSmpKR0NTSDBXb3JsaE1RNFowMC9zK0Vvd09j ZFR6NEVRS05BQ1RFMWxucDlpSVlySw0KN2dpME44Wlk2V1ZEd1BVOHhsMXNxam9zVmVWZFA2L3Ba VVhUcTlzMWZmZFZ4WG9mQWxxVy90Skp4TXNZDQp3NHVSaW1sRmcyVzVTdDloV3FaeXhETFlhdlVh U3VUU3JoZEtuQTh1QnVmOWwyK3Z6bDZjL2ZSMitQcnkNCjh0WFY5ZGxwc1pwN2NmYTIvL3I2dVdD aWdRUUpkaEpQMTNENnlLaHNHU2pYcnFFU21wcVVJMlBxVFFlMA0KVzM3QWpuOWNkVnhFaEU1dEJq YklrZGxPUnZXclZZbGhxamFZMUViYXhDVUdncUk1OFRpS2YyWmo1bU8xDQpBTFNubVovSU0yKzhS VkV2ak9SeTFTa2J6QlJhMVZUZlRGMFcyb1BzRnZpVThqcy9icWhMZWRBckZ2bkINCmZTSHB3L3E0 S0l0TVFuU29TeU1GOHMwYk9YL0hpemhSRUdyWDZ5cE16THNPdi9uVmJqMC92ZXFJNFF2eA0KYm5D cU8rTG5rN09yNjg0djdpL0lRK2NYMm9FUzR1ZkJhWWJIcEJ0YTkvVlJCelJKMDM5Wng3VzQyTnZo DQp5ZjBQb3R2OW8ydTArL1dIYmxkVVJNbEtVWGpPdTdxSDE3Q2ZiWXQyOStzVzRZTnI0Sng2cEVl cE1tNzENCkVBSm1POW9Gc3pFOVRkeHFHRkY0cjRBUFpYZ3pVZ2x4YUx4Mmk5aVlGMFNvTEV0NTVi TFIyTkVCb3NZNw0KSnFUdHh5YWcyTXlwcG1RcGNFTGFlamJjWlJLdWRrVWlkQUxtdWNyY1hJS01a dzVoTHlrM3VZekZTdEoyDQpRNFh2VlBrQmNjdUpUbmF2blArUnFmL0xNcldTWm1BRHZzNkgwdS8z WHJacmZuQm1VV1ZyN2JkS2RsZ2ENCmliREJseWUwVitDcGtOdGltOUhtUXFBSHZQdWtzMXNxQXBL VXFiN0xoQ3BsODd2dEc4dWNkKytxdE9TRA0KMjdMY3NRT0FUSE55ZDNpeFUwdkVpUFpvNXdoeTA3 d1FUcGpZTkM1S0lTNm5MenI0bllDVnBJMFozaVNJDQphR2N0bHNaYlQwVWxpZ0dVMkI3Q3hRMnQr YzRILzE2RHJtTGp2bUViWUZFNTZ0M2d5SFcydzdzRExPQnQNClU3bGRvZXFDYkpPMllOMEZZQW5i bTVkaFk1dk9tdFN2WW05NE9kaDNVVUMwajdVUG5LSGNKSEVlYXFBVg0KbTFQdDBvUXh5Z0hVYlpv dzlNRjVGUnZWQ1JxUkUzYTFYd09Xa2JDU3RERUEvRzllZi9nQmVYV1VjQ1NCDQpnZGxLL0JUclNo ZERUSVhLUU5JTmdVU3JTNHFrdW95YlVWS3hpU3RVd1NhdVZCRVBMRlR3VnJyVjNhSTUNCnNLaDJs RHRMNHBNQ3A5MHFsQWlSdzV0Yjk0dU82cEZEWXhUeVdMSXdTOE5NbmJwRnRsclh0djU5NG02cw0K N292aWRuSjExcjgrZTN2eWZQRHk5QzFhL1Irc2NSZDdOUWZ1aCtxRmd2SGlUSDk4cWRvNTR0MnZp NHptDQpyQmFwemNVa2hUeWRyOTRuZWp1OE9BUUFsMEJKdnBiaVZFOG1XbldmcXppZXc5VitGOWNC SlJRdTg3anYNCmdLMmNucUpMdTFWYXJNdVRRWHJNVnk0Q0F0ZkVxeEhBTUQ0clZ4SkFEd2lUTkk3 OTZpak45RlRUYWUybA0KeWlaMDZQVXN6VmJTWmNDUWp0akdhN0YzK1d5NDMyNFZlVzNBZ0NVZlI1 S3lLbUU0WWVDTHB4alB6dWIrDQpTQTRrajR0UGRYOWdjNHNoVTZTbEVYdGhoODJmRTV6N0lCK2N1 a014YnIvdm9FWGVBYjkxMzRqYlhOTnUNCjFYeVQxWHhURVhiYk5ZNG4zT1diUnZIS1k1OWJXek1L ajhwREQ5NFlyV01DcmVFOUdCU2x5cE9NZ2twcw0KVm14L2dsS2NZOTdQcERSVTZGdmYxcStzWlVh MU01cjdrTUJpcVhCdkdsZ3VMdXBFc04xeVRGRDhGaUtJDQpRVXhaSXo0akVTd0UveFFtMkZUQWJ6 MmVRSFV2Q1dKeGtnZUtLTzdORU84Ykd6c09pc3JMSDNjeXhWMzENCmZoUGM3c0VVeFRaUnBBcDRI NlpZT1VQN3NseXhkbHBWbzJQdEZuTkc4ZW1Va2RQS2NVYngwWlNSRmhUMw0KRGJtZFJETHNMOXpL Sk1VMmtmeHNBZmpGQ09WbUVOVXBKVjNhUUgrekFlcGwzYWdpdFF4VzgzUHU2bE5xDQpzaEUvSDBO Q0MzRDRmMDlEaC8zOWpyaVZrLzRNanRiNTVZdlRVa3liWWRvcU0vMGtmdEJ1MWIxMUwzNVENClE2 QmliejhTdSs0MVZFN1dpaHRSOXlLbWpVeWlmbDVmcWV1bExPSGsxNC96akU5dGphY1p1N1pqTHpi Mg0KTkZ4QTMrK3NvcnhjdHJWN1c0RUZ5bXgzbTlNekN6blNNWlVmR0t2NWNNOWw5ZjB1aWdUYzhB ZWpBeXZvDQoyTWJkSGZYSDc0N1JtMHFpTlFiWlljT3pvNFpuMzZML0FWb2ZpVy9GUS9GSVBCYmZp U2ZpKzQ5NTFtNzkNCmMvYzMvbXUzM29zTGNMTEMyZUw5eVhzQXhObnc3T3JQOEJRK0Z4S0hKaS9k MVNYL2V2OTVwQ2l1R1F4Tw0KOS83bFlQODlvLytRS2kxOURGTDRVOEt3ZExtbUU4TFBLRVhBaE4r TGlqaGk3MUNrWTZ2c3Z1Z1dXSERRDQpvMWFsakUxTk9rQUNTUWY0blB0dVliTkFQTHR0OWQ4M0ty TjM1QVl5MVpIKzhvY0w1ZTRsVFpYMUMxMisNCklqRG9YL1QvOGtlWDNPNnhOTFJ5OURYenZzZUY1 VHBwSXpHTCtnengrVXBtdUY5VEE4dW16TDhWVUVQRw0KODdMVDNiV3NiM2plbWIxYjRMcmpZbEhZ ZW1PU3RWR29DMlRwaEV1cE80VWhJS3FpNXAxWXZVdThkdXVqDQpMajdkSWpSdCtSSklpYnN3NnVB ZkNQWFpFWXBIclNMVWt5K0ZVS1d1L25YSGRuMzk5YjVoaUk5OGZXbW8NClBid2JhcCs0ZkhNYll2 ZTRING91RCsvUnBhUmVYd3l1YjhQTndnNTdELzJzdExId3BDTEJybUJ3dnphbw0KNzc5dWJJaTZK cFZyR3R4a1kyUE8wMExTZ3U1aTB0ckZ3VlI1SjdEeUs1cUpXL2V1MHVvVjJhcnhpcjJLDQpCL3dE am5hcnNRMlVzdExteG4xOHdMOFRNalpiOTV3YzJvUmRBYlo0dStVc3lyODRXcVNhVnUxaDBWVDAN CkxNRVJ4SGZ3N0tkaTU1Wit6TWh6V1o2Njh2b3plZXUzTEpaMlgyUFllbDAvUGQxZWplOThjZXZp S0xpTQ0KZ0cwSHZYSHhIdGJRalp0L3U2NEJoUDBHbnhqdTFub0RpNWFWaTV4K203bnhlakZmRGdt L1J2TFVlNlB5DQp1YUZvMjRVV0wzeURXeGIzcXR3ZUg0WFY1dURGM25oTjNGV2FmRzNwMW12TVN3 eXNuZjNVdmZyQkJQL1ENCnEwZ0IvbkVMeFVSbS9YemhGQ2tybC9MMDQ2Y3dzcE9wR0pzYzBoL1Rw bEtzSXY1VkJEdGlTUGNzWlV4Nw0KUXNtTkVkT1V4cmlVZVN6ZXBEbjlrS2hEOFVZLzZCak8xeVpP bDQ2ZzlCT2JKbXYvcC9nWjFVaU9iK2o5DQovd0JZSUowR056d0FBQT09DQoNCi0tPg0KDQo8L3Jm Yz4NCg0K --000000000000fcb07505c6e4da6d-- From nobody Sun Jul 11 21:18:54 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 84AA33A2E09 for ; Sun, 11 Jul 2021 21:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, NICE_REPLY_A=-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 fZMu56Rg5a2F for ; Sun, 11 Jul 2021 21:18:47 -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 B85F93A2E04 for ; Sun, 11 Jul 2021 21:18:47 -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 <0QW421IAA6NBNO@wwwlocal.goatley.com> for ipsec@ietf.org; Sun, 11 Jul 2021 23:18:47 -0500 (CDT) Received: from blockhead.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0QW400C0F6KLRY@trixy.bergandi.net> for ipsec@ietf.org; Sun, 11 Jul 2021 21:17:10 -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, 11 Jul 2021 21:17:09 -0700 Date: Sun, 11 Jul 2021 21:18:44 -0700 From: Dan Harkins In-reply-to: To: Paul Wouters , ipsec@ietf.org Message-id: <37455b5e-a7b7-3730-e947-b6abed348eb3@lounge.org> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_rxVhGQg6A17FThdVEchd5Q)" Content-language: en-US User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 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: <162545902175.31867.5147837556210174666@ietfa.amsl.com> <6b574666311b4885983df4b26b158953@huawei.com> <4e62fa1c-292-a14c-9ea9-2e9cad3e88f8@aiven.io> X-PMAS-Software: PreciseMail V3.3 [210708a] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [IPsec] I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 04:18:53 -0000 This is a multi-part message in MIME format. --Boundary_(ID_rxVhGQg6A17FThdVEchd5Q) Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 8BIT   Gee maybe someone is blocking email :/ On 7/11/21 8:38 PM, Paul Wouters wrote: > Hmm, it used to be that if you are subscribed to one IETF list, you > can post to any of them. That does not seem to work for the ipsec list :/ > > > ---------- Forwarded message --------- > From: *Paul Wouters* > > Date: Sun, Jul 11, 2021 at 11:34 PM > Subject: Re: [IPsec] I-D Action: > draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.txt > To: Panwei (William) > > Cc: ipsec@ietf.org > > > > On Mon, 5 Jul 2021, Panwei (William) wrote: > > Hi Wei Pan, > > > According to the discussion on the mailing list, I update the draft > to version 05. In this version, I deleted the unnecessary > considerations for the configuration changes. For now, the solution is > very simple and just includes the negotiation at creating IKE SAs and > optimization at rekeying IKE and Child SAs. > > > > Comments and feedbacks are more than welcome. > > It is lookger much better and simpler, but I still had a few issues and > wanted to make the document a bit shorter and clearer.  I made some > changes for your consideration. I've attached an updated xml and txt file > in case you would like to use my changes. The changes are: > > - Reduced the text that was used to explain a lot of IKEv2 basics. > > Instead, a reference to IKEv2 should be enough. This greatly simplifies > the text. > > - Remove the parts about "changed configuration". > > If the crypto parameters have changed, you SHOULD NOT use REKEY. RFC 7296 > says this: > >     In Section 2.8, "Note that, when rekeying, the new Child SA MAY have >     different Traffic Selectors and algorithms than the old one" was >     changed to "Note that, when rekeying, the new Child SA SHOULD NOT >     have different Traffic Selectors and algorithms than the old one". > > So if the configuration has changed, you should not do any kind of REKEY, > whether it is OPTIMIZED or not. You should do a re-authentication (in > other words, a new IKE from scratch) > > - IKE REKEY MUST contain KE, because RFC 7296 says: > >     The main reason for rekeying the IKE SA is to ensure that the >     compromise of old keying material does not provide information about >     the current keys, or vice versa.  Therefore, implementations MUST >     perform a new Diffie-Hellman exchange when rekeying the IKE SA.  In >     other words, an initiator MUST NOT propose the value "NONE" for the >     Diffie-Hellman transform, and a responder MUST NOT accept such a >     proposal.  This means that a successful exchange rekeying the IKE SA >     always includes the KEi/KEr payloads. > > - Removed: It also helps to avoid IP fragmentation of IKEv2 messages > > I don't think this is actually true, since on rekey there are no required > CERT payloads, which is the vast majority of the payload size in IKE_AUTH > that causes fragmentation. > > - Changed MINIMUM_REKEY{_SUPPORTED} to OPTIMIZED_REKEY{_SUPPORTED} > > This matches better with the OPTIMIZED_REKEY notify. Also, I find that > "minimum" is a little confusing. It could mean "minimum lifetime" or > "minimum of the previous one". I find "optimized" covers this better > than "minium". > > - Shortened titles > > For improved readability of Table of Contents > > - Some grammar and style > > Open questions to the working group: > > 1) Should the SUPPORTED notify mean that peers MAY use this method or MUST >     use this method? There could be a use for making it MUST, as a peer >     could then eventually stop supporting the "old method". Initiators >     would know by the lack of the notify that they might not be able to >     rekey in the old way, and must add/delete or re-auth the SA. > > 2) Alternatively, the SUPPORTED notify could have a payload that signifies >     whether the old method is supported or not. > > 3) Should we look at supporting rekeying multiple Child SAs at once? Or >     should we tell people they should have used additional Traffic >     Selectors and combined the Child SAs into one ? > > 4) When a Child SA was negotiated with PFS, what should an optimized rekey >     do when there is no KE payload? Send INVALID_KE_PAYLOAD ? > > > Paul > > > > > > > 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: Monday, July 5, 2021 12:24 PM > >> To: i-d-announce@ietf.org > >> Subject: I-D Action: > draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.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-05.txt > >>      Pages           : 9 > >>      Date            : 2021-07-04 > >> > >> 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 is also an htmlized version available at: > >> > https://datatracker.ietf.org/doc/html/draft-kampati-ipsecme-ikev2-sa-ts-p > > >> ayloads-opt-05 > >> > >> A diff from the previous version is available at: > >> > https://www.ietf.org/rfcdiff?url2=draft-kampati-ipsecme-ikev2-sa-ts-paylo > > >> ads-opt-05 > >> > >> > >> 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 > > > > > _______________________________________________ > 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 --Boundary_(ID_rxVhGQg6A17FThdVEchd5Q) Content-type: text/html; charset=utf-8 Content-transfer-encoding: 8BIT
  Gee maybe someone is blocking email :/

On 7/11/21 8:38 PM, Paul Wouters wrote:
Hmm, it used to be that if you are subscribed to one IETF list, you can post to any of them. That does not seem to work for the ipsec list :/


---------- Forwarded message ---------
From: Paul Wouters <paul.wouters@aiven.io>
Date: Sun, Jul 11, 2021 at 11:34 PM
Subject: Re: [IPsec] I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.txt
To: Panwei (William) <william.panwei@huawei.com>
Cc: ipsec@ietf.org <ipsec@ietf.org>


On Mon, 5 Jul 2021, Panwei (William) wrote:

Hi Wei Pan,

> According to the discussion on the mailing list, I update the draft to version 05. In this version, I deleted the unnecessary considerations for the configuration changes. For now, the solution is very simple and just includes the negotiation at creating IKE SAs and optimization at rekeying IKE and Child SAs.
>
> Comments and feedbacks are more than welcome.

It is lookger much better and simpler, but I still had a few issues and
wanted to make the document a bit shorter and clearer.  I made some
changes for your consideration. I've attached an updated xml and txt file
in case you would like to use my changes. The changes are:

- Reduced the text that was used to explain a lot of IKEv2 basics.

Instead, a reference to IKEv2 should be enough. This greatly simplifies
the text.

- Remove the parts about "changed configuration".

If the crypto parameters have changed, you SHOULD NOT use REKEY. RFC 7296
says this:

    In Section 2.8, "Note that, when rekeying, the new Child SA MAY have
    different Traffic Selectors and algorithms than the old one" was
    changed to "Note that, when rekeying, the new Child SA SHOULD NOT
    have different Traffic Selectors and algorithms than the old one".

So if the configuration has changed, you should not do any kind of REKEY,
whether it is OPTIMIZED or not. You should do a re-authentication (in
other words, a new IKE from scratch)

- IKE REKEY MUST contain KE, because RFC 7296 says:

    The main reason for rekeying the IKE SA is to ensure that the
    compromise of old keying material does not provide information about
    the current keys, or vice versa.  Therefore, implementations MUST
    perform a new Diffie-Hellman exchange when rekeying the IKE SA.  In
    other words, an initiator MUST NOT propose the value "NONE" for the
    Diffie-Hellman transform, and a responder MUST NOT accept such a
    proposal.  This means that a successful exchange rekeying the IKE SA
    always includes the KEi/KEr payloads.

- Removed: It also helps to avoid IP fragmentation of IKEv2 messages

I don't think this is actually true, since on rekey there are no required
CERT payloads, which is the vast majority of the payload size in IKE_AUTH
that causes fragmentation.

- Changed MINIMUM_REKEY{_SUPPORTED} to OPTIMIZED_REKEY{_SUPPORTED}

This matches better with the OPTIMIZED_REKEY notify. Also, I find that
"minimum" is a little confusing. It could mean "minimum lifetime" or
"minimum of the previous one". I find "optimized" covers this better
than "minium".

- Shortened titles

For improved readability of Table of Contents

- Some grammar and style

Open questions to the working group:

1) Should the SUPPORTED notify mean that peers MAY use this method or MUST
    use this method? There could be a use for making it MUST, as a peer
    could then eventually stop supporting the "old method". Initiators
    would know by the lack of the notify that they might not be able to
    rekey in the old way, and must add/delete or re-auth the SA.

2) Alternatively, the SUPPORTED notify could have a payload that signifies
    whether the old method is supported or not.

3) Should we look at supporting rekeying multiple Child SAs at once? Or
    should we tell people they should have used additional Traffic
    Selectors and combined the Child SAs into one ?

4) When a Child SA was negotiated with PFS, what should an optimized rekey
    do when there is no KE payload? Send INVALID_KE_PAYLOAD ?


Paul



>
> 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: Monday, July 5, 2021 12:24 PM
>> To: i-d-announce@ietf.org
>> Subject: I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.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-05.txt
>>      Pages           : 9
>>      Date            : 2021-07-04
>>
>> 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 is also an htmlized version available at:
>> https://datatracker.ietf.org/doc/html/draft-kampati-ipsecme-ikev2-sa-ts-p
>> ayloads-opt-05
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-kampati-ipsecme-ikev2-sa-ts-paylo
>> ads-opt-05
>>
>>
>> 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
>

_______________________________________________
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
--Boundary_(ID_rxVhGQg6A17FThdVEchd5Q)-- From nobody Sun Jul 11 22:25:52 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 0AD673A335A; Sun, 11 Jul 2021 22:25:47 -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.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <162606754698.29754.6648616889913689679@ietfa.amsl.com> Date: Sun, 11 Jul 2021 22:25:47 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-g-ikev2-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 05:25:47 -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 : Group Key Management using IKEv2 Authors : Valery Smyslov Brian Weis Filename : draft-ietf-ipsecme-g-ikev2-03.txt Pages : 60 Date : 2021-07-11 Abstract: This document presents an extension to the Internet Key Exchange version 2 (IKEv2) protocol for the purpose of a group key management. The protocol is in conformance with the Multicast Security (MSEC) key management architecture, which contains two components: member registration and group rekeying. Both components require a Group Controller/Key Server to download IPsec group security associations to authorized members of a group. The group members then exchange IP multicast or other group traffic as IPsec packets. This document obsoletes RFC 6407. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-g-ikev2/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-g-ikev2-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-g-ikev2-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 11 22:30:50 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 E184D3A33AA for ; Sun, 11 Jul 2021 22:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[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 3sSk3jXAvWYp for ; Sun, 11 Jul 2021 22:30:46 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 15BEA3A33B3 for ; Sun, 11 Jul 2021 22:30:34 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id i5so11053988lfe.2 for ; Sun, 11 Jul 2021 22:30:34 -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=zcdyrs0ac19iLd7SRoht0ZrDrqlbEHyE7cfCCRRVoQM=; b=OoS+xj3B0Vf+UMD2+zzg0Ft2mZBhdkDUoHcmmHAnaSo5f96VAHwSlgwsG96XbZdg/E wqp9T96zfBAFzFXA0NpjYNmdZR+XAiqIt+BjOYGBpQBDX0yp50P0O50oepnEzfWg+K0K m1PXjA0EwbdGp9o/ArZImJYjVPnGclZwQwX5eI2MNhpkR1i1Pn3dV43KImBCE3MTvq06 dGjGWnd3I0fLoo0siBWVjzmokCf7biJkz/IVkeaaqZSTqfPTvidO9EMyTyyeYccSXCIn YN4Z0NJzUD0j4XJCCIJ1tuOoaeO63KYdC7BVsuBK6U9dzAzvtBIFoCsxNcAXcBUecoB7 4x1g== 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=zcdyrs0ac19iLd7SRoht0ZrDrqlbEHyE7cfCCRRVoQM=; b=RYOkBng1dRReYknSoYd0lVIRHXqa/iUz3bbVqDFqb34rgD6G20bFSJ5wtg7+mrpJmp XhrihGRGnTsTf5H8A5MIsbhDtWRUcEeofS3O0nNYCV3jvbF24OHeC9M+JObY4S4aSgLd HT8DyPJ3aKvlDN9Tos4O/aWwDw3yAysD2Ur1CDrNe4iBMFSC+F6w9SftmiGcBZnZqkCp ZSu8FprpuW4LomTfaNk4yDrD1RucD+tcepn4kM0Zcq8XriqM3slMjYqfN8kxJ3lgjWnU 7E9RCSurHGdZt8iMS63bEc8WCE+hUJiUTdnnrNNQjxFpUPydzM4QdtjDKPJIP5bqC6Sv qFMw== X-Gm-Message-State: AOAM530RYFj7SII8Swfj+rBxV/p2d1dSGCZuftuEXKQkZeB4bnBkqMpR a24HGBeLvINVJ/EjY3vE15IpzwLFIDQ= X-Google-Smtp-Source: ABdhPJyGVSRfzc9JtRrSOnT8UyixriygzL9klWOey3Vc7O/y8ODLkHRJyg2ZOooaLTpi3W09W8rSBA== X-Received: by 2002:ac2:4d82:: with SMTP id g2mr3265494lfe.565.1626067831917; Sun, 11 Jul 2021 22:30:31 -0700 (PDT) Received: from buildpc ([93.188.44.204]) by smtp.gmail.com with ESMTPSA id z15sm91692lfq.113.2021.07.11.22.30.31 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Jul 2021 22:30:31 -0700 (PDT) From: "Valery Smyslov" To: References: <162606754698.29754.6648616889913689679@ietfa.amsl.com> In-Reply-To: <162606754698.29754.6648616889913689679@ietfa.amsl.com> Date: Mon, 12 Jul 2021 08:30:30 +0300 Message-ID: <0f8101d776df$0815a5e0$1840f1a0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGCRfAoLfVLpvmHx1vefTYZHS2+c6vpMcWw Content-Language: ru Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-g-ikev2-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 05:30:49 -0000 Hi, a new version of the draft has been posted with minor editorial changes. The draft has been still waiting for reviews. Regards, Valery. > 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 : Group Key Management using IKEv2 > Authors : Valery Smyslov > Brian Weis > Filename : draft-ietf-ipsecme-g-ikev2-03.txt > Pages : 60 > Date : 2021-07-11 > > Abstract: > This document presents an extension to the Internet Key Exchange > version 2 (IKEv2) protocol for the purpose of a group key management. > The protocol is in conformance with the Multicast Security (MSEC) key > management architecture, which contains two components: member > registration and group rekeying. Both components require a Group > Controller/Key Server to download IPsec group security associations > to authorized members of a group. The group members then exchange IP > multicast or other group traffic as IPsec packets. This document > obsoletes RFC 6407. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-g-ikev2/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-g-ikev2-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-g-ikev2-03 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Jul 12 07:54:35 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 559A73A1BE0 for ; Mon, 12 Jul 2021 07:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[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 UNOzc7mMPoMb for ; Mon, 12 Jul 2021 07:54:30 -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 B137A3A1BDD for ; Mon, 12 Jul 2021 07:54:29 -0700 (PDT) Received: from fraeml703-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GNmj86gCRz6GFq9 for ; Mon, 12 Jul 2021 22:43:24 +0800 (CST) Received: from kwepeml500004.china.huawei.com (7.221.188.141) 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; Mon, 12 Jul 2021 16:54:26 +0200 Received: from kwepeml500004.china.huawei.com (7.221.188.141) by kwepeml500004.china.huawei.com (7.221.188.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Mon, 12 Jul 2021 22:54:25 +0800 Received: from kwepeml500004.china.huawei.com ([7.221.188.141]) by kwepeml500004.china.huawei.com ([7.221.188.141]) with mapi id 15.01.2176.012; Mon, 12 Jul 2021 22:54:25 +0800 From: "Panwei (William)" To: Paul Wouters CC: "ipsec@ietf.org" Thread-Topic: [IPsec] I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.txt Thread-Index: AQHXcVWcdoeDBz6MZEq61ZUG3CA6GKs0BS1QgAovtQCAAUEiIA== Date: Mon, 12 Jul 2021 14:54:25 +0000 Message-ID: <27e6c017e1a740b2b2fd9c4e65e9804a@huawei.com> References: <162545902175.31867.5147837556210174666@ietfa.amsl.com> <6b574666311b4885983df4b26b158953@huawei.com> <4e62fa1c-292-a14c-9ea9-2e9cad3e88f8@aiven.io> In-Reply-To: <4e62fa1c-292-a14c-9ea9-2e9cad3e88f8@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] I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 14:54:33 -0000 Hi Paul, Thanks very much for your suggestion. I've updated the 06 version based on = your changes. The draft looks much simpler now. Regards & Thanks! Wei Pan > -----Original Message----- > From: Paul Wouters [mailto:paul.wouters@aiven.io] > Sent: Monday, July 12, 2021 11:35 AM > To: Panwei (William) > Cc: ipsec@ietf.org > Subject: Re: [IPsec] I-D Action: > draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.txt >=20 > On Mon, 5 Jul 2021, Panwei (William) wrote: >=20 > Hi Wei Pan, >=20 > > According to the discussion on the mailing list, I update the draft to > version 05. In this version, I deleted the unnecessary considerations for= the > configuration changes. For now, the solution is very simple and just > includes the negotiation at creating IKE SAs and optimization at rekeying > IKE and Child SAs. > > > > Comments and feedbacks are more than welcome. >=20 > It is lookger much better and simpler, but I still had a few issues and w= anted > to make the document a bit shorter and clearer. I made some changes for > your consideration. I've attached an updated xml and txt file in case you > would like to use my changes. The changes are: >=20 > - Reduced the text that was used to explain a lot of IKEv2 basics. >=20 > Instead, a reference to IKEv2 should be enough. This greatly simplifies t= he > text. >=20 > - Remove the parts about "changed configuration". >=20 > If the crypto parameters have changed, you SHOULD NOT use REKEY. RFC > 7296 says this: >=20 > In Section 2.8, "Note that, when rekeying, the new Child SA MAY have > different Traffic Selectors and algorithms than the old one" was > changed to "Note that, when rekeying, the new Child SA SHOULD NOT > have different Traffic Selectors and algorithms than the old one". >=20 > So if the configuration has changed, you should not do any kind of REKEY, > whether it is OPTIMIZED or not. You should do a re-authentication (in oth= er > words, a new IKE from scratch) >=20 > - IKE REKEY MUST contain KE, because RFC 7296 says: >=20 > The main reason for rekeying the IKE SA is to ensure that the > compromise of old keying material does not provide information > about > the current keys, or vice versa. Therefore, implementations MUST > perform a new Diffie-Hellman exchange when rekeying the IKE SA. In > other words, an initiator MUST NOT propose the value "NONE" for the > Diffie-Hellman transform, and a responder MUST NOT accept such a > proposal. This means that a successful exchange rekeying the IKE SA > always includes the KEi/KEr payloads. >=20 > - Removed: It also helps to avoid IP fragmentation of IKEv2 messages >=20 > I don't think this is actually true, since on rekey there are no required= CERT > payloads, which is the vast majority of the payload size in IKE_AUTH that > causes fragmentation. >=20 > - Changed MINIMUM_REKEY{_SUPPORTED} to > OPTIMIZED_REKEY{_SUPPORTED} >=20 > This matches better with the OPTIMIZED_REKEY notify. Also, I find that > "minimum" is a little confusing. It could mean "minimum lifetime" or > "minimum of the previous one". I find "optimized" covers this better than > "minium". >=20 > - Shortened titles >=20 > For improved readability of Table of Contents >=20 > - Some grammar and style >=20 > Open questions to the working group: >=20 > 1) Should the SUPPORTED notify mean that peers MAY use this method or > MUST > use this method? There could be a use for making it MUST, as a peer > could then eventually stop supporting the "old method". Initiators > would know by the lack of the notify that they might not be able to > rekey in the old way, and must add/delete or re-auth the SA. >=20 > 2) Alternatively, the SUPPORTED notify could have a payload that signifie= s > whether the old method is supported or not. >=20 > 3) Should we look at supporting rekeying multiple Child SAs at once? Or > should we tell people they should have used additional Traffic > Selectors and combined the Child SAs into one ? >=20 > 4) When a Child SA was negotiated with PFS, what should an optimized > rekey > do when there is no KE payload? Send INVALID_KE_PAYLOAD ? >=20 >=20 > Paul >=20 >=20 >=20 > > > > 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: Monday, July 5, 2021 12:24 PM > >> To: i-d-announce@ietf.org > >> Subject: I-D Action: > >> draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.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-05.txt > >> Pages : 9 > >> Date : 2021-07-04 > >> > >> 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-pa > >> yloa > >> ds-opt/ > >> > >> There is also an htmlized version available at: > >> https://datatracker.ietf.org/doc/html/draft-kampati-ipsecme-ikev2-sa- > >> ts-p > >> ayloads-opt-05 > >> > >> A diff from the previous version is available at: > >> https://www.ietf.org/rfcdiff?url2=3Ddraft-kampati-ipsecme-ikev2-sa-ts-= p > >> aylo > >> ads-opt-05 > >> > >> > >> 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 Tue Jul 13 15:49:32 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 3B2D53A104F for ; Tue, 13 Jul 2021 15:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hpe.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 s18ObNZHruIH for ; Tue, 13 Jul 2021 15:49:26 -0700 (PDT) Received: from mx0b-002e3701.pphosted.com (mx0b-002e3701.pphosted.com [148.163.143.35]) (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 0B6153A104D for ; Tue, 13 Jul 2021 15:49:25 -0700 (PDT) Received: from pps.filterd (m0150245.ppops.net [127.0.0.1]) by mx0b-002e3701.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 16DMmGUT024187 for ; Tue, 13 Jul 2021 22:49:22 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hpe.com; h=from : to : subject : date : message-id : content-type : mime-version; s=pps0720; bh=WoU54hExy6Q1pXNRxR1pTjEDmW0IvzFSR/nMFA0IA5c=; b=EkHr9sT7pqFBQc1enyRz/is91vekd+bA8569dmqSU6gWN7Wek4SZSP6Sgkbo/sAXEEN2 RqC+Go/TonNrVWg6PhxpqWFie0Wu5grxs5ZV0zl/TSwE7DOAc/P8yNG0Q3WdH7tCUyN1 SGb7M9dt501Cwqvj3AsEeQ8zOCVzdsEfCnj8wqUPG7BXH6ioPw6pFtn71t92o4/cBOXm 4eKpDz8sZ2Y6OzVPmORVQUqQfwpvTq8BEP1ztHIs6S1elGq9iUupFwya0i1hz03mGvBr 7Y6nulWpyI6IoLik7NG6inPLA1XSl/ynfRgTA+B5DoatHhnke1osNDVJ3/cPRyoprIKV +Q== Received: from g4t3426.houston.hpe.com (g4t3426.houston.hpe.com [15.241.140.75]) by mx0b-002e3701.pphosted.com with ESMTP id 39scx63rau-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 13 Jul 2021 22:49:22 +0000 Received: from G4W9121.americas.hpqcorp.net (exchangepmrr1.us.hpecorp.net [16.210.21.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by g4t3426.houston.hpe.com (Postfix) with ESMTPS id 16BFC70 for ; Tue, 13 Jul 2021 22:49:21 +0000 (UTC) Received: from G4W9121.americas.hpqcorp.net (2002:10d2:1510::10d2:1510) by G4W9121.americas.hpqcorp.net (2002:10d2:1510::10d2:1510) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Tue, 13 Jul 2021 22:48:38 +0000 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (15.241.52.12) by G4W9121.americas.hpqcorp.net (16.210.21.16) with Microsoft SMTP Server (TLS) id 15.0.1497.18 via Frontend Transport; Tue, 13 Jul 2021 22:48:38 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V7rOuKKXj7JNf4jiNwWJ1D3MVANOmVPbQrGI1kjxdADeNlGFwUIsXl9WuHbSQJueOl7hcjsw8Pz3m9rrVotnaWPnPrWjJ3NL6/iuwvm+flaZIYsKXtRVV3RrSIaoSwlgWg3oX4mDfTaSOEfg3+4fbdrRYbFxndA3umUGDGu0mFPwHQbh4zsCUcZCs/1bD9Q8//VbCZRDUE/Kk1joPmRZK97obBtQe1q0I7TELOIa/1EGa3aAFoYBwVEkJf2NTYkNq+IdnYnaCxiG//iiaN8ZieAe2Ux0pUyYpXkgtm4/M1eLACQM4IK6ZQ1VMQtm+PyR7wA4YHi7d2NDWHNyowrlIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WoU54hExy6Q1pXNRxR1pTjEDmW0IvzFSR/nMFA0IA5c=; b=Eni3zzhNu4Fn2P3iX3/RYwNZ3a6FAk9XuhUERwWyJywOC1ze4ccu6D9fX/kuADuv0f0EemYF1zItgW/LWujYCXHCoYBmyD53ANVDdQ8/z+n1EmNTXp3FZ5DoS4zxScco7s3lWtDsNwG+qQMCnNVjv4RZkupWSYf5szu12L4VNKIwzDXDtBqBHUtJci680Kwr1Ja5xtLCXM0tBbfP+aDOe4MHuC2PbEw0mmom8bwcp5X/mlb5b1vWuIWnacDKAbhg5l3mijGcBGRuzo7AwIxDbLS6ZJbTyqIMKS3/djVcB3b+uRu0zRDs/y54ABZCf7Ix4gh6jVSCP8jD1bKJQQxMow== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=hpe.com; dmarc=pass action=none header.from=hpe.com; dkim=pass header.d=hpe.com; arc=none Received: from CS1PR8401MB1192.NAMPRD84.PROD.OUTLOOK.COM (2a01:111:e400:7507::23) by CS1PR8401MB1144.NAMPRD84.PROD.OUTLOOK.COM (2a01:111:e400:7508::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.20; Tue, 13 Jul 2021 22:48:37 +0000 Received: from CS1PR8401MB1192.NAMPRD84.PROD.OUTLOOK.COM ([fe80::a4ff:aeb9:d100:6536]) by CS1PR8401MB1192.NAMPRD84.PROD.OUTLOOK.COM ([fe80::a4ff:aeb9:d100:6536%9]) with mapi id 15.20.4308.027; Tue, 13 Jul 2021 22:48:37 +0000 From: "Bottorff, Paul" To: "ipsec@ietf.org" Thread-Topic: draft-bottorff-ipsecme-mtdcuc-ipsec-lb-00 Thread-Index: Add4OOvDB8BvW/+gSTKdXHebf/BVNg== Date: Tue, 13 Jul 2021 22:48:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=hpe.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c048ff7d-0ea2-4a68-9d38-08d946505a0c x-ms-traffictypediagnostic: CS1PR8401MB1144: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: q1KCrkE0LeVycFvP5DjfHZmJSGOMrk6o7n8YP0sIDFfW5Ci8Zin/6Zlq2trFYoQQDJWFW43Cf4PdV9eGfRX+xrlVvDX2ipUGxLev2f7wFdIFIP6skaLK7/G+Q1cWnGddmshRkceaVsLIYkTcLCLS8B1ilrLlESS9DNMXyBAixw1ga39Q3oVa1nMb3FIBdoV29hbjg27E0nhEHLD4SieSuruKIxf4lf6aqWkt9SK6jyix842yrLRG4m3nlPclbMXCdGzcDFHjjHVx+U/kgF8sy/QGi0UjXHKMYvn/8NpTxUhc4eHwfTnP1F1IdBXRuvgVQjmS5PxwZSDNQWyloa1rSPIJWxrXoH0uyqr6hl34AcHh5DdTuj5hLJxQM5I8ij4mVbBxetLPG5ux4l0sS+PZh/j2A08vNjOSAVPyXAxXqPlhM9nr5XGoGCHlQmidilINtDThfuSK32dUB8JYVYnUW2TpdTfWfq9dQ3ebT1xqQmfwdjsJN31seiT2IyA7ezt59+f9Y83BGX24lyTCfgHy7B27IUaXRM3kSoLeEUVNc/Ltup4ruTXUWvG3X0IS57PH4yqAl6rg3uVqJEOxNXUNaNQ48sf2aeduIIwvc2lFoGrxQ64YeSGrEXL6gx4ca6PjYED8kY69VJKSUY0bogTRDAPtwOgTwzoWLd68OSkHoTi82D3bGIfehsq+jATWJuJi5fuwXUeEnIQWMY/09X0lBQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CS1PR8401MB1192.NAMPRD84.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(39860400002)(136003)(366004)(396003)(376002)(346002)(33656002)(38100700002)(6506007)(66446008)(2906002)(9686003)(186003)(478600001)(122000001)(26005)(8936002)(8676002)(83380400001)(76116006)(316002)(86362001)(55236004)(71200400001)(5660300002)(64756008)(7696005)(52536014)(66946007)(66556008)(66476007)(55016002)(6916009)(38070700004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?YtEEMPs0v+vW2ETeefTo8GAN8k1wMgGilcS2ptc93EIINv3ASRBs9l4YGxJr?= =?us-ascii?Q?iGheStMKtceizFXhxjUJKZVEkxXFCcjKmUt94Omr3o8p2zTb8x74wLXJkZje?= =?us-ascii?Q?HnTZZmb6YdfyWFxdci25NS/262tDTBT/2bu5jpsYll/NZUxiTI+8zkeBtYdw?= =?us-ascii?Q?HUv/dWfS7w9o3JT61zQdO5l2QAUyChYxzzbsd5dGQQe7Me7589KqLi2DpNWs?= =?us-ascii?Q?ZafAE1RZimuKzlvP8J46E+Sv4ef/ZRgxurfoeEFlgJWQV9vFuro+Bgl9z6CG?= =?us-ascii?Q?X1ha8EyZM48IQFNrKePyIDRzxXemP9pMK4ELp+XMCotNoHW7drDBhd8mvEds?= =?us-ascii?Q?K6C/43Z+NzmuvfGUbcvIhJPCKO1bjoy2POeuXf8p14NL/U4jei8HT96vg8db?= =?us-ascii?Q?ykIfsGyyhQcn8EPDEkVbOGPwMCViZ/UfRjICiADxzxr/1JTeNYi7SjT5aXrX?= =?us-ascii?Q?inSfHvxD+gFJ3xuK7qbJioi4KtnCA+6Ouf//JHLn91uIuTT9UxBpBde/ZT4M?= =?us-ascii?Q?rTh1PJyBaw8CbPC4xeffyPdPaUOM9FgV4PXW20ItnDvVsgAx2V5TgwzFca8O?= =?us-ascii?Q?f27q0Zuz2GzQRAq5sCcBnN+1CYF9ZGIeE8LmXHmWPyZh6xdiriq0vf4r42Ie?= =?us-ascii?Q?zTN6p78L2/k/4Rdgij8MRfFxbfygFFbi2X/y0t0x6VP1J+LoHQw31woGuCbO?= =?us-ascii?Q?MsN5fNiMtOZyIonot8Pm6c5oal4skWrfYXChmuxISuLWgYH4etDwjPQkqe86?= =?us-ascii?Q?Owziqb/AQQGDP5GW4v0B82jHlbBg52a1oHWzyl4cGv8SlY3A5deT0RWFHd1/?= =?us-ascii?Q?xwWiSjtNdK34Upsi3oP6Zj6Qvod/At9onG6vpYenj8sGZUKCmPyMKX7Ktzs+?= =?us-ascii?Q?jf9CPN7DDIma+xvMqZXLRk5ifRXHMC0HUaB2jp6q0rw7C6hnhQnl4YiYnhcg?= =?us-ascii?Q?yGhgIvR8fDdlP+kCirOV8qOHuFlWdJO0CuNzbA3zbrVm1fujRekLmft7ywGF?= =?us-ascii?Q?WTNUf9VwmCsvTKcaeD2VHK24BT85MLndXW4Fwjxo+NXj46AoJjmtQQLm4loO?= =?us-ascii?Q?CKGbnpY47s0R4pjW6AxWYxDI8eoBo2fcMGcS0auSAihRB8HmfViaIgTiT0QK?= =?us-ascii?Q?fMhrwuuUiSfE21TrYuQm/nyiuXTUQDm//VQNVEbcriqheCnPkyyI7cj+lxVc?= =?us-ascii?Q?kPfoTFzQpr5gBU4B/Fljq4ZAgPgxp5qN6hv1hOJsh2scMdJAgY6c+tp3O5sd?= =?us-ascii?Q?Cpc1aLf7LWbbnu+k+nZ1rFn2APU4SK9+9GK9pFhdmjosmMy6rrhJTCThoXFt?= =?us-ascii?Q?OKQNzT/ucsOHKVlhZXQpHwRn?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CS1PR8401MB11925233C65D61668B40CC0AFE149CS1PR8401MB1192_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CS1PR8401MB1192.NAMPRD84.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: c048ff7d-0ea2-4a68-9d38-08d946505a0c X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2021 22:48:37.0700 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4kQqDe/r7R5mhnlAP+Y9n8qKKWcWL0jKuQA7iuwsCairezhF9OIPNx6LjZNg/rJkDiZAreG51BV+7BptGpadVQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CS1PR8401MB1144 X-OriginatorOrg: hpe.com X-Proofpoint-GUID: RSW1QmzGpIcXVl4HWjFL47Ne9q5kLkRw X-Proofpoint-ORIG-GUID: RSW1QmzGpIcXVl4HWjFL47Ne9q5kLkRw X-HPE-SCL: -1 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-13_12:2021-07-13, 2021-07-13 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1011 impostorscore=0 mlxlogscore=665 bulkscore=0 adultscore=0 mlxscore=0 lowpriorityscore=0 phishscore=0 priorityscore=1501 spamscore=0 suspectscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107130138 Archived-At: Subject: [IPsec] draft-bottorff-ipsecme-mtdcuc-ipsec-lb-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2021 22:49:30 -0000 --_000_CS1PR8401MB11925233C65D61668B40CC0AFE149CS1PR8401MB1192_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: A new draft-bottorff-ipsecme-mtdcuc-ipsec-lb-00 has been posted in the ipse= cme documents which describes a use case for IPsec load balancing. Name: draft-bottorff-ipsecme-mtdcuc-ipsec-lb Revision: 00 Title: Multi-tenant Data Center Use Case for IPsec Load= Balancing Document date: 2021-07-05 Group: Individual Submission Pages: 11 Abstract: IPsec is of increasing importance within data centers to secure tunnels used to carry multi-tenant traffic encapsulated using the Network Virtualization over L3 (NVO3) protocols. Encrypting NVO3 tunnels provides defence against bad actors within the physical underlay network from monitoring or injecting overlay traffic from outside the NVO3 infrastructure. When securing data center tunnels using IPsec it becomes crucial to retain entropy within the outer IPsec packet headers to facilitate load balancing over the highly meshed networks used in these environments. While entropy is necessary to support load distribution algorithms it is also important that the entropy codes used retain integrity of flows to prevent performance deterioration resulting from packet re-ordering. Here, we describe a use case for load balancing IPsec traffic within multi-tenant data centers. Cheers, Paul --_000_CS1PR8401MB11925233C65D61668B40CC0AFE149CS1PR8401MB1192_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:

 

A new draft-bottorff-ipsecme-mtdcuc-ipsec-lb-00 has been posted i= n the ipsecme documents which describes a use case for IPsec load balancing= .

 

Name:        = ;          draft-bottorff-ipse= cme-mtdcuc-ipsec-lb

Revision:       &= nbsp;      00

Title:       &nbs= p;             = Multi-tenant Data Center Use Case for IPsec Load Balancing

Document date: 2021-07-05

Group:       &nbs= p;          Individual Submiss= ion

Pages:       &nbs= p;          11

 

Abstract:

   IPsec is of increasing importance withi= n data centers to secure

   tunnels used to carry multi-tenant traf= fic encapsulated using the

   Network Virtualization over L3 (NVO3) p= rotocols. Encrypting NVO3

   tunnels provides defence against bad ac= tors within the physical

   underlay network from monitoring or inj= ecting overlay traffic from

   outside the NVO3 infrastructure. When s= ecuring data center tunnels

   using IPsec it becomes crucial to retai= n entropy within the outer

   IPsec packet headers to facilitate load= balancing over the highly

   meshed networks used in these environme= nts. While entropy is

   necessary to support load distribution = algorithms it is also

   important that the entropy codes used r= etain integrity of flows to

   prevent performance deterioration resul= ting from packet re-ordering.

   Here, we describe a use case for load b= alancing IPsec traffic within

   multi-tenant data centers.

 

Cheers,

 

Paul

 

--_000_CS1PR8401MB11925233C65D61668B40CC0AFE149CS1PR8401MB1192_-- From nobody Wed Jul 14 09:43: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 A0A1B3A241F for ; Wed, 14 Jul 2021 09:43:27 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=labn.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzXdq5fre2f3 for ; Wed, 14 Jul 2021 09:43:22 -0700 (PDT) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2123.outbound.protection.outlook.com [40.107.220.123]) (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 D3FC13A23F3 for ; Wed, 14 Jul 2021 09:43:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=foEDJGThJKxV9k6+q9VRlhB0vPdZtFO/rRZl5CBAuJ0kXyyP95KV+Xx9IVenFDG3fQIciZ7qsfwYfSUCRFXDN9y61Y7tZtQGapF7/naOb+7PVBYc2eQc2ykbo7BJDIdP/Cvd4Z+a7i76gEz5zcL7g524CAwG4zKoRVobADg303gSU6B5KbqviwKylgO3+rJt8xE1dZTMPEAe7YuUuS7dgyMff8KT5hTqd4G0hbd1WvPy9zEcC2snt5d6whJIAhliufvIv6gMZqWupXh/kR4QJQbdYRgEvIRtDv//1J/TV3vjh27c/yEXDcKdwPljbKmF86ITQKbHOPnAcr6+cd1kjw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Go91a24hcQoLFwvqejEJQSd3oaw2z98pKq3kUohRrH0=; b=TKFdklzLKaCBUDInWLKUO/tTtODXoe53s7ETVrtIMPrGKOSXhICG5fbmIIdFCPkNEtdSLIOZgZuQmmtuFkZsqaHNPF5/OyWP4ybwBuwCk/4r5NqznYpmJgxe1TR0fLvUHCCsuPREDIJbuiS97TYr8462O1AzgfsvAc/Ex20WgcGdrLpz39MDp4jw4AlcwFwaNZgodSUikENTIhy4hwdH1FMbPdTd3p+wPv1f7wIZolLD88mFbGznEvUmQsrEwBh190HI2f7mvZzmIB4shJ8xtNvFBHks2NgaGxMjcGreXH9J4WObpTGPdZrzYnrQhwM8Sr8RT8RR5Xrp3hEjWMDBfw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=labn.net; dmarc=pass action=none header.from=labn.net; dkim=pass header.d=labn.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=labn.onmicrosoft.com; s=selector2-labn-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Go91a24hcQoLFwvqejEJQSd3oaw2z98pKq3kUohRrH0=; b=FppRQrP1CdvO/P9SVr354CwLy0HuM4qmEg9XHwrbS33EWAOUk7fi27N2+ME3mjP8q2Y/lQLJYhkbyh/lI1HmU0CdVXXygJTv10RxHkbRE0tu62aLWDMEAkw4/5cFAvm+KRZTa3cdzUkN1yjdklpEqYr8RuDM8lxjtv3fMOmWY4s= Received: from MN2PR14MB4030.namprd14.prod.outlook.com (2603:10b6:208:1dc::14) by BL1PR14MB4966.namprd14.prod.outlook.com (2603:10b6:208:31c::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.21; Wed, 14 Jul 2021 16:43:20 +0000 Received: from MN2PR14MB4030.namprd14.prod.outlook.com ([fe80::905a:7886:33e9:534b]) by MN2PR14MB4030.namprd14.prod.outlook.com ([fe80::905a:7886:33e9:534b%9]) with mapi id 15.20.4308.027; Wed, 14 Jul 2021 16:43:20 +0000 From: Don Fedyk To: "ipsec@ietf.org" Thread-Topic: Requesting WG last Call for IP-TFS Management drafts Thread-Index: Add4z0wsZbeUMYY/SYCBFUCDppWM0w== Date: Wed, 14 Jul 2021 16:43:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=labn.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 35bcfbe6-8d39-4aad-d760-08d946e67d0e x-ms-traffictypediagnostic: BL1PR14MB4966: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WrOo9r6IO6Jv9ZwM8nYK09qA4ItAMqd3rmz4mP/CpxSBjOfv+JLzzD9YouH8x3XryouObAgOIazza/H9/ZLBkHoUWCwAQihtu5xwOisg7g70Vb3DO46Yf73E2EfNCENqoKBXEPfcZ3rCHYn/UOIMZ5WaQrzr439IX6sQ2J4sj4fS7ENJKkMii5VaweA9Sl+aQca8zfLq9P+IYny7NlSXml4MCNuakI3qoN4Q38IzJ9uVa+JAutnOcwmcLMU7XNTRLkix8WEpgv/AEYbIKwwUfev0e5z+vWphopEeizjMsBCCXPAdzV0fPPsCN4qR1jomXVCfPE8eWi/fEESHfs/YM9x+ULVbX2BA12EYEn8sR5bfM7dKMYH/pltG+nYMf4Le7Bfk4rwS7geC34fVA8h9DR4cOLMfQ5G1WnsyNvrsFp2AE2gtEwE/fV0nba1pBPfYw66/zAwnBPdeC7Kdakk60hLQjV5L/j4PL557IQ9Jx+De3zRIzR0ZDasTXlrFx4pLImb3Y9bKf7RAYXh16zD5R7nfcLKT/NI3Jy3ihfO4mlGWkyI01oxg2gXAF5XYJV/6ywUvM5edqMJVlV00Rq76WqrQhK1utSXWUO4pQhaTpTFT8ZnwoVcSp1liTCUFO1aYIiNC/GRk7HLyuKee5FegfQVCUxbsiPsJvLPMlRwflJ9G0m+yJgR8CB73Xh8M2LCg61g80ZZzT9qjKljoeIQV8Shna6yaSVUeh9hPOh8/r0fRgAYp+5sCbSfs0loUt4ZYsI6WpkcKuHs1Q+opVG2ufX86GQlP+X5nsJwRBMmh4+E= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR14MB4030.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(346002)(376002)(39830400003)(136003)(366004)(7696005)(316002)(52536014)(558084003)(9686003)(478600001)(86362001)(6916009)(8676002)(186003)(66946007)(122000001)(76116006)(71200400001)(966005)(66556008)(5660300002)(66476007)(33656002)(8936002)(55016002)(64756008)(66446008)(166002)(6506007)(26005)(38100700002)(2906002)(83380400001)(38070700004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?RlDKLHYWZbcvahp18OplBM8F7kLPChYbUyFibRElaJZARkKvSZKETEEcj9zc?= =?us-ascii?Q?GWXuXj5sAWSXPJE09+3cKb9XNG/I3EDCGG6o58Y55IrOBzSC5bsnmaq+hRV3?= =?us-ascii?Q?EUl54UyL4o/dtvqwW1FVF2HreciWpBUkHjJS0ZV5lRyN4xzEueQsiIIo1RVn?= =?us-ascii?Q?34vr8Cg8xNZFGG3pt9u5+sGVCB5KX9RmCRDCvKpkEqb9Q9pMff4sUBoB9OZh?= =?us-ascii?Q?MEw5/yFMW6I8SdjV6Hd4te6TDH/fzj+2IbxvXukDwmy+lrMCbpnsKpTZL3bM?= =?us-ascii?Q?Sq3Uz/TH/8gN/4HR2INQTgZRGwzk7bYKm9EeBfBDbwV1lcm8NZ31fSFZljtU?= =?us-ascii?Q?gngtzTS0kepZ2eGf8MdLqnRliiYJbUxijY0pJzSDbSdOv2QclKJvLVTxJSgw?= =?us-ascii?Q?5r8lIk0rfDesFw2iKQhGcp0V/HhnIEMdd4Vo9oLMNnwCKtVYCiLq7tw/lRqM?= =?us-ascii?Q?djV9o97rwH5kCMzrs116pOoVLoI6tVmAiT5dUeoLxx4SIwO1GsiEBJWrrrU8?= =?us-ascii?Q?KsYMrSvs64uO2XEeU8j68BLe/2bbH5WGTrhRcarXxk2+qwIh1ycru/1pVr8Y?= =?us-ascii?Q?ehMs7P5LumbtMfhUxxB2RnIdKHlsMmyGnOvcmdvvSEyxLU6QoPNh7WHcfzlZ?= =?us-ascii?Q?nMW1QLr2RIU0G0I3DPO6Ag10/HbA79rpMG/Risqw+u7Rv0Reqxq31k0+qiMy?= =?us-ascii?Q?NWG927CfATBnEUf14/4vRkYx4aoDI/XMvy4ugs7xgaBuYvmRwXCBEqKpO4mH?= =?us-ascii?Q?Rhsdk9wWRjOtwmlBrGXrsGWzuCMKUfXf8au38oQeICw35yq0kQSRrxq61IrY?= =?us-ascii?Q?1LYY9wzS6mOCpTmxNotNzxcJ8FL1l3HhlCzMJLpzvs6wEVD9vCw7Sz53MSiT?= =?us-ascii?Q?rVhK/uMrdVVWRh5qHtWJJBvt4uuLNm0COUUxYW4zbFi4rqrfmGs5kVn95/1S?= =?us-ascii?Q?ZiiIZdyrYUUFrF5vU+MwVfglGOB2F1y+LxqK6x3SmNiR85He2ytGk9ul4d5S?= =?us-ascii?Q?DZ5eu8JP6Um5pTfZ/Ay9QdC7RtPuC02ty0sjAHZak6TfOKtOXkjPkW2tfNtn?= =?us-ascii?Q?2wgXPxujkAAXUuDIxAk+bKxpJmUgA7IDJOiOqHIiQgOd40Gb8PVxVfrqxssJ?= =?us-ascii?Q?JWBhy5MeuNlgBGnPn3VyBV2FLqRWKVwQ0gyWms083+dKgUApWmii4q0pm0m0?= =?us-ascii?Q?9tfXlSkXud1d25imVFO4/1Ot92GHuWYbJkswoNkrCCy8xjtyyvY/J4+eeOCB?= =?us-ascii?Q?9XffEn421wBaOljJ9VJn9w4Akfjdv8zKws4MDzYDytqEEXCdf5e9TNus2zKq?= =?us-ascii?Q?QlSalu8q22txuH8yHj+jRG1L?= Content-Type: multipart/alternative; boundary="_000_MN2PR14MB4030966A488FEEC637711C13BB139MN2PR14MB4030namp_" MIME-Version: 1.0 X-OriginatorOrg: labn.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR14MB4030.namprd14.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 35bcfbe6-8d39-4aad-d760-08d946e67d0e X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2021 16:43:20.1365 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: eb60ac54-2184-4344-9b60-40c8b2b72561 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 3N59Sx4OBTk9eV1xUx01ntXPHPISzqO3js2037lBQsJvfjzmi75m5Cvww7LnM7Po26Jy/HejChAcf9jNYzZTYA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR14MB4966 Archived-At: Subject: [IPsec] Requesting WG last Call for IP-TFS Management drafts 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, 14 Jul 2021 16:43:28 -0000 --_000_MN2PR14MB4030966A488FEEC637711C13BB139MN2PR14MB4030namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As we plan to request WG last call for the IP-TFS Management drafts during = the upcoming IETF ipsecme meeting, please review the following: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-yang-iptfs/ https://datatracker.ietf.org/doc/draft-ietf-ipsecme-mib-iptfs/ Thanks Don and Co-authors --_000_MN2PR14MB4030966A488FEEC637711C13BB139MN2PR14MB4030namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As we plan to request WG last call for the IP-TFS Ma= nagement drafts during the upcoming IETF ipsecme meeting, please revie= w the following:

 

https://datatracker.i= etf.org/doc/draft-ietf-ipsecme-yang-iptfs/

https://datatracker.ie= tf.org/doc/draft-ietf-ipsecme-mib-iptfs/

 

Thanks

Don and Co-authors

 

--_000_MN2PR14MB4030966A488FEEC637711C13BB139MN2PR14MB4030namp_-- From nobody Wed Jul 14 16:12: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 B978B3A0C19 for ; Wed, 14 Jul 2021 16:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hpe.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 OvnMcVqA-gXf for ; Wed, 14 Jul 2021 16:12:46 -0700 (PDT) Received: from mx0a-002e3701.pphosted.com (mx0a-002e3701.pphosted.com [148.163.147.86]) (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 1A5513A0844 for ; Wed, 14 Jul 2021 16:12:45 -0700 (PDT) Received: from pps.filterd (m0150242.ppops.net [127.0.0.1]) by mx0a-002e3701.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 16EN8Jm9025414; Wed, 14 Jul 2021 23:12:44 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hpe.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=pps0720; bh=oa0t4/vaURfAkhUT323GYRxim7TIIolaKuHBDHXvCic=; b=QSmwX3KQOf5KtIfSjsU/o7bpH7pUBsesiCg9gVWiE/sSL1VzTDJ7CYU2Q7716QYWBJ8j GpUD9Zex6LC0K0L4imRsqQqy/8xz/48pBa+DYfNkrxgtana/dpOPI1l3SckT9OHvdt08 cpGrzy6AU3XxpS0mzy7rrf1BwYh62tIQ+xWrDrhfeTwezx7lcSRP1LeezpUyEzRJKDtt JOdacmVJ3OaB7xq/LUkEJIORpzYUVDB1CKUVJl/unSj98ICggbXjHM9sNY2KGtmjmwlW nlmN58CLER/sIPZ5dM/1rzrUArzi0uvWtKjCEspx7KgWDNqHL35crJd6JBN+gKBARdgf nQ== Received: from g2t2353.austin.hpe.com (g2t2353.austin.hpe.com [15.233.44.26]) by mx0a-002e3701.pphosted.com with ESMTP id 39t1x741a0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Jul 2021 23:12:44 +0000 Received: from G1W8108.americas.hpqcorp.net (g1w8108.austin.hp.com [16.193.72.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by g2t2353.austin.hpe.com (Postfix) with ESMTPS id F158565; Wed, 14 Jul 2021 23:12:42 +0000 (UTC) Received: from G9W8453.americas.hpqcorp.net (2002:10d8:a0d3::10d8:a0d3) by G1W8108.americas.hpqcorp.net (2002:10c1:483c::10c1:483c) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Wed, 14 Jul 2021 23:12:42 +0000 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (15.241.52.11) by G9W8453.americas.hpqcorp.net (16.216.160.211) with Microsoft SMTP Server (TLS) id 15.0.1497.18 via Frontend Transport; Wed, 14 Jul 2021 23:12:42 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GRRVDiCObSc/4DxvxwdxoXSrOBvREn9odxgNu4GwhT829NbPjs5W4yoqLxNOa5gmAGLU4BeIESBVNiwOvMFPh8zSW6vneNl+WlyvX3gpz8I/311KVB5AdAKxubO7k/iEM0rWpwpjFalmSGI3DE0YtcG7pCPRsmlt/S/g8OUztNUgM/3HaT9bfeQhtDUSD2YN5zyKxztkhOfR6nyLufRal4uJh83x0l1CYHnuRLuDWpilDlNRV84dPaPnk/eol/8SvMQlynt+5A/rJTAh3xkwY3RmibvOlUU7vdddC88pa4LpcDANbE8oEvAHzsjSnKV5s3pMRjtQ6N4AvaBwBqJMgg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GOo9tngObtM+l5C+JsHdjNedZa1hcGjqyULs0sEf3U0=; b=jVXKOLfgFYbIzIrl3X0uDr/GOZoUghNRJ2qtw8rsVFjb2SSzW44VgEmDlhNwj8mQgecsFw/Reg54m6xxVHfzoz/wPcs6LZL05/awoCIa4tMacqlC5saPYXHGrHFZ8SNvko6jnZkOJv02I5Z2S+5NT1YXBNpuDZ+S47QRSwG8sPwQGDIVnmIkJMMfRhRpdFOGamyvtOMm1kfZyAFFCKzh57Xtehrsi+o/QyewuPvhklELOU/+TNilm059FMZxNHnN3Q0XsdP/CBaBeBwkVdJ6dkzBIBsMDWm+OjqjbaT0nhm+jtRLMVSQolhy+5lv3dEgCXOSbLPaS8bFXmrasZJS+Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=hpe.com; dmarc=pass action=none header.from=hpe.com; dkim=pass header.d=hpe.com; arc=none Received: from CS1PR8401MB1192.NAMPRD84.PROD.OUTLOOK.COM (2a01:111:e400:7507::23) by CS1PR8401MB0951.NAMPRD84.PROD.OUTLOOK.COM (2a01:111:e400:7510::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.21; Wed, 14 Jul 2021 23:12:41 +0000 Received: from CS1PR8401MB1192.NAMPRD84.PROD.OUTLOOK.COM ([fe80::a4ff:aeb9:d100:6536]) by CS1PR8401MB1192.NAMPRD84.PROD.OUTLOOK.COM ([fe80::a4ff:aeb9:d100:6536%9]) with mapi id 15.20.4308.027; Wed, 14 Jul 2021 23:12:41 +0000 From: "Bottorff, Paul" To: "Bottorff, Paul" , Valery Smyslov , 'Tero Kivinen' , "antony.antony@secunet.com" , 'IPsec' Thread-Topic: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07 Thread-Index: AdciaiROLLoGnn3oQyW5+9ys0PMxKgJRErFpANOS/JYCNRDTH6tGNXFQq2XEr5DWKZkDwA== Date: Wed, 14 Jul 2021 23:12:41 +0000 Message-ID: References: <20210331103220.GA21137@moon.secunet.de> <24678.19440.553333.890224@fireball.acr.fi> <036401d72786$91047b90$b30d72b0$@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: hpe.com; dkim=none (message not signed) header.d=none;hpe.com; dmarc=none action=none header.from=hpe.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 968b0c06-e859-49c4-c448-08d9471ce134 x-ms-traffictypediagnostic: CS1PR8401MB0951: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3173; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ybqf43mheu6BlIMWKZM3bmo3XqM59PM1fcuW4qX2Bkw1pPxnbuCMEOiiDybSZQxQO5ljH8LUnbXksOAC8d4VqrBB/TcLUg1qLfHc8Qyjz1aWrbE+31VuCmpxCXl74J6Jk5DS0dvQUwCWVNRtjjEdDvmvO3GnTsBBx4Og7WD3fivekNS0t5dUO1ghDKK8W/Xr3NiALoFqmd3fXHgpS9O+YrcS/A4mxskeEb9EYnCtfZlmdZpoj+0iNNCHpT6NHqxuKi+SkrqRHghv1Py40gj+DbJ1EsIE45PeUSr2/3wCxuljR2Bnf4eGyJqwIgDlzTOe3dPuRtNWjNgtup9Ao0BDJq5RT2+I1TTUqSviCYlqVqAapzbvZ2pa7ENpC1ahsf1Hto8I0Avrpz7wMVbO2yEeV01crYCA+hvDAOgZ6BOTc9HKmObAGb9Z1TMfuimIZDF+LJ9gBT8y9Z3M/rxROA3c6z7c3kEaVcjoq9e7s9nshOs8QVaPoMKpiePcwZAXKC92KofPuDuPROfH1enF2Zc7XTznFU2otSZPVNp37xvWpK5Z9jR5yisjbR5N4tO5QWcvoVBK/bZw6Y2XgH4sfMs+Zv0KnxSPnIh6woM+Z9Di2YSKWyLm0foJOydsRjgzKrXBAz2DrwKqj9nrzA2ZdLVCxS7HhvkCapx3WHisD6VFWZSCfthv7Yv1qu+45/BlvmEMCW13ED6THt8kci7n/JLKb1g7tmGLEVnmv927rSea9LkRnOVxkZdJoxR4OGXOV9Xet42R+geQC8+cN9qTE6Jh36vz5sHqSf8pTIG54MRpl6c= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CS1PR8401MB1192.NAMPRD84.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(39860400002)(396003)(136003)(376002)(346002)(53546011)(26005)(186003)(66446008)(2906002)(8936002)(122000001)(9686003)(7696005)(55236004)(38100700002)(71200400001)(478600001)(6506007)(316002)(966005)(55016002)(33656002)(52536014)(66556008)(66946007)(76116006)(5660300002)(110136005)(8676002)(64756008)(86362001)(83380400001)(66476007)(38070700004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?4yUri4HoLJDytfxxYiCGs8ZJ12dlY0MOzT8up+yIc+Tqd6rkCn/WehMSP2l6?= =?us-ascii?Q?/9wqpIN8c3e56Br1o4liYzNk7qAGuehEQiiGls5BSUxmBer6EIGSBh5G0LVO?= =?us-ascii?Q?n1ikYWD/eKt5VQwa36phHLjWQhMupCQLwL4TXesM6uUIxrr9EYrhKwp9Xxay?= =?us-ascii?Q?4F0wcLOjE5NSyDSjX2+9VWw9m4MpIvAmXmorXLwOn3yX6nseddSp305m7zdb?= =?us-ascii?Q?l4gM736ZW6a4iDIQDIe7zbd+z/iq/i3VFh90Zcp80W4PNpSxjNry1CaD0nTN?= =?us-ascii?Q?f0YPYQefdLfCKK/eofAyjgTusGlYN4irXpyHy7sT0f8NdolL0Bx+p9OW41+i?= =?us-ascii?Q?FPoDkhqA9TVtkditGEqnG2tBSveAjC4EKO7vH1ixpQurAlSh0Po5RUKIwfv5?= =?us-ascii?Q?meu674RO0VUrR7lZsXZFPiSNYFlVPvt3n+V7xpHshqTR6wbHePG5yFAPVpcw?= =?us-ascii?Q?SAUK4uYScFaPGtbsFYmTZP3VnhjuVRkN0URE2bqFZUPxoTcFjZSJ5te1E9/2?= =?us-ascii?Q?NF4otUO1V15O5zPLbWRK4YaOiZeVhliW18Kw0A0b+mdfJKIt2QMS7+TYuU+E?= =?us-ascii?Q?bXUbtC4xT/T0y85gW6kS65QCqWhmUmJZs3diVe0yOU8tpZlkySW3JqA0lQV2?= =?us-ascii?Q?/ZUzQKif7EuLezzcV5GAY7VnfXuHAsxdwKkeQKKSPwjaZrhXIxtgAP3f9XHY?= =?us-ascii?Q?rUc6NCsPUrgv7rIH4MtCTrtsgrfuVXVLrfNGY3NDo0lpFmvgZo+X7D2wP4Hx?= =?us-ascii?Q?xWer1/F8kqoo8SA78ea5oKg310uA/WEkNXVtL8KmJYVFNKSJkyECKyhnEEXR?= =?us-ascii?Q?nVN2gAKHHluPR7MYo1vDxTqjip27bUe/2RyX8aJrgQKKFuN52SJdJanZo64l?= =?us-ascii?Q?dVUUx3VfREM8rkg7v//B4l8H7yliw0Vp5UDRVxMEHC+SHXisg1u4NRQBmzj2?= =?us-ascii?Q?YY3YJ9u1+OpDDTOtCXzR189MhXLUnnAxf3cG7nN66MGPc9BxhyvFcQxcPCkn?= =?us-ascii?Q?Jr+8p5Q6/KeUcvavQn/zLTdjkq0iYaSZ/PqYka7JmiBib8iIZOY89fx/B2OJ?= =?us-ascii?Q?RBmLWM0Kv4A//w4SmWn9y/nTRSVr+Tgx2PXsnry5BJ28b0jxWmH+xkOG9auK?= =?us-ascii?Q?930q70SNcGWnsQZMCAsmotRkPWgTNfaCTVsQPjokQslMID4WEgLecxKqzmCh?= =?us-ascii?Q?j0h0p7sCwJSpYGKQyZgu3hTKkEL5rQao1zqETf+k9eye61C/LPs1Qq0sKv7J?= =?us-ascii?Q?ByvAT+dDvRHUzQzNcqDe14mLph4OKfoELNbyCfp8T2ObWGScxNcrtWiDB8PO?= =?us-ascii?Q?BC8Fu1O48tic+yXRfLiv2JcI?= Content-Type: text/plain; charset="us-ascii" X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CS1PR8401MB1192.NAMPRD84.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 968b0c06-e859-49c4-c448-08d9471ce134 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2021 23:12:41.1514 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: IO0m5eKTsdNj01SBVsd07zhknQrueGnJvhtFUr82ZVKBXQU6vscIUqLwY2cQv3hNzDzsBZcWMi6GqvEtV/8qvQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CS1PR8401MB0951 X-OriginatorOrg: hpe.com X-Proofpoint-GUID: lAD5bF-Sbhtote3MT9-PagGpYnPxDYTQ X-Proofpoint-ORIG-GUID: lAD5bF-Sbhtote3MT9-PagGpYnPxDYTQ Content-Transfer-Encoding: quoted-printable X-Proofpoint-UnRewURL: 1 URL was un-rewritten MIME-Version: 1.0 X-HPE-SCL: -1 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-14_11:2021-07-14, 2021-07-14 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 suspectscore=0 spamscore=0 clxscore=1011 adultscore=0 mlxscore=0 malwarescore=0 bulkscore=0 priorityscore=1501 phishscore=0 impostorscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107140141 Archived-At: Subject: Re: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07 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, 14 Jul 2021 23:12:51 -0000 Hi Antony, Tero, Valery: I've put forward draft-bottorff-ipsecme-mtdcuc-ipsec-lb-00 to show the use = case for esp in udp load balancing I'm concerned with. This case does not r= equire NAT traversal. With that said I've spent some time looking into NAT traversal and believe = it is possible to combine LB and NAT. To do so the responder must not respo= nd with the source port received in the ESP in UDP packets. Instead, the re= sponder should use the port received by the responder in the IKE exchanges.= I believe this means turning off dynamic port updating when combining NAT = with LB, which does mean that a change in the NAT mapping for IKE packets (= resulting from a NAT timeout or reset) could result in packets being lost, = however this event would be rare. Though there may be ways to cover this bo= undary case I don't believe it is worth the effort to fix this problem to s= upport long term use of IPv4. Though my application is not concerned with RSS, it does seems using MOBIKE= to generate entropy for RSS is very clumsy since this requires assigning n= ew IP addresses just to force entropy. The LB proposal seems the best way f= orward for a general RSS solution. Cheers, Paul -----Original Message----- From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Bottorff, Paul Sent: Friday, April 2, 2021 2:59 PM To: Valery Smyslov ; 'Tero Kivinen' Cc: 'IPsec' ; antony.antony@secunet.com Subject: Re: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07 Hi Valery: Agreed that LB only needs control of the source port to provide entropy.=20 Our application is for traversal of highly meshed data centre fabrics. We e= ncapsulate and de-encapsulate at the server using smart NICs and so don't h= ave any impact on RSS or host software (nor improvement over their standard= operation). We perform the encapsulation/de-encapsulation after the ESP pa= cket is formed. Since encapsulation occurs after and de-encapsulation occur= s before the IPsec stack, IPsec does not see any of the new port assignment= s so we don't have any issues with the SADB or IKE. Cheers, Paul -----Original Message----- From: Valery Smyslov [mailto:smyslov.ietf@gmail.com] Sent: Thursday, April 1, 2021 11:08 PM To: 'Tero Kivinen' ; Bottorff, Paul Cc: 'IPsec' ; antony.antony@secunet.com Subject: RE: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07 Hi Tero, > For the load balancing I think it is enough for just one of the ports=20 > to be different, thus initiator could simply allocate n random source=20 > port numbers, and initiate IKE from each of them to responder, and=20 > then create SAs for each of them separately, thus allowing load=20 > balancing using UDP encapsulation using existing hardware. RFC 7791 + MOBIKE can be used to clone IKE SA and move it to a different l= ocal IP+port. Regards, Valery. > -- > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > INVALID URI REMOVED > man_listinfo_ipsec&d=3DDwICAg&c=3DC5b8zRQO1miGmBeVZ2LFWg&r=3DCCwOcKkISkWx= d8Y > my11M8VW3U6Peq8aJ_DDlgVbQW5E&m=3DykseXYzNH5MG1guNwTPMGiGby4o46mBhv92vwoS > pb0U&s=3DnCqbPzmEc1xdTkL0jPmKmNgH252j3dURPVnH8bt4OtE&e=3D _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec=20 From nobody Thu Jul 15 01:36:03 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 E19E93A2277 for ; Thu, 15 Jul 2021 01:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=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 obUvz3H8J_Me for ; Thu, 15 Jul 2021 01:35:59 -0700 (PDT) Received: from mail.strongswan.org (sitav-80046.hsr.ch [152.96.80.46]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5275F3A2275 for ; Thu, 15 Jul 2021 01:35:58 -0700 (PDT) Received: from [IPv6:2a01:8b81:5407:c100:a9d4:9b76:d080:f43c] (unknown [IPv6:2a01:8b81:5407:c100:a9d4:9b76:d080:f43c]) by mail.strongswan.org (Postfix) with ESMTPSA id D8C4740060; Thu, 15 Jul 2021 10:35:55 +0200 (CEST) To: "Bottorff, Paul" , Valery Smyslov , 'Tero Kivinen' , "antony.antony@secunet.com" , 'IPsec' References: <20210331103220.GA21137@moon.secunet.de> <24678.19440.553333.890224@fireball.acr.fi> <036401d72786$91047b90$b30d72b0$@gmail.com> From: Tobias Brunner Message-ID: Date: Thu, 15 Jul 2021 10:35:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07 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, 15 Jul 2021 08:36:01 -0000 Hi Paul, > Instead, the responder should use the port received by the responder in the IKE exchanges. Note that if these packets have random source ports, this will only work if the NAT implementation plays along or there is static port forwarding configured. NATs might filter inbound packets from endpoints that don't equal the IP/port to which the host behind the NAT originally sent packets when the NAT mapping was created (address and port-dependent filtering in terms of RFC 4787). I guess the same could happen in scenarios where there are no NATs but restrictive firewalls that block traffic from endpoints to which the host behind the firewall did not send traffic. Regards, Tobias From nobody Thu Jul 15 10:15: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 1B5243A0EC9; Thu, 15 Jul 2021 10:15:00 -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 az61Xr2RmLCE; Thu, 15 Jul 2021 10:14:55 -0700 (PDT) Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (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 C36FA3A0EBD; Thu, 15 Jul 2021 10:14:49 -0700 (PDT) Received: by mail-yb1-xb2c.google.com with SMTP id g5so10227335ybu.10; Thu, 15 Jul 2021 10:14:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ghnJY+LDcTNJNTbuXJIcf1DAAm/tMaX7x2XkRSxgT8Y=; b=ozr7bgwZbRG6jHs3gns6SRv0UDPOfFOaTzhbydV0bqIHS8KXEMAoTTG2/1lM2b3RBQ jYaz+h33fuACsJByB6PXGYpkCQFsKlx08b18KRez8aTXEitApnjqrG08OF0xGGxahA1B eVdUCwqauWwWu7dFWZkgYwQGRI5IfWGHpl2AdllYfc/JsZJZ1YiwGP9J+C/kn4kk80yc 7YLOtJ/B/Zoct0eJflNjrNdlfgXQXTLLq0fV4QUJqJB6lSobbcQLG8xNv11SmcD4lVb7 s/8D0ok5NLdff5LPPG7uPv3G2uD1WPDzd2mX5CdRIgeOssErB+Hl3+ogf/fH4EM+Wd0L x1uA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ghnJY+LDcTNJNTbuXJIcf1DAAm/tMaX7x2XkRSxgT8Y=; b=a18z7e+OqUD05Vr7fJTC5fEwzuqQOtHJFSu5Xnrl9bBcbz8Bj4BlqybX4x44aKmbLe vZ8wXsNC/DXkk+Yz7BvGhTWkxEhRDIqHESYbkVbqOGpPttXThrpcK9w0BEvixE0qs4Km 3DtDGp9Yo7Ie1Ra6FUKh5D0Rh3JD4MJ6+7MzBJMzYlmBS+LGS4nsVF9CQGa51wHxjoqh jw+A+NH9aAVnQ9uZDp+gTSQ9bX25WE4niJCjKeYvnqeEl2WbCZz9KI6zsgybDx9OK4ie xCgnwQWUNhnaV9ml9RGP4EiYe5kkA2n4yuGr+3kL3sZsjGVoBoUwFYaEMpzZegGTsvSd J40w== X-Gm-Message-State: AOAM5321TERnIr+n1hxigNrbB/hzdSxzsifoOdDmvHMaiupfFtymVWNn G2U8uKtXGSdQ4VDA34hBZ6jAPSfU/O1Yhr6fghWZ7H35vY4= X-Google-Smtp-Source: ABdhPJzCwWyhB1YJ9d35OvCjxk6xDf9/4a8Nj+l2pDQDaJ8FxYYaSHU2T83sMdHmL9dVxPVQDM2aDrcZSyl75Y/raOs= X-Received: by 2002:a25:442:: with SMTP id 63mr6717568ybe.114.1626369288178; Thu, 15 Jul 2021 10:14:48 -0700 (PDT) MIME-Version: 1.0 From: Daniel Migault Date: Thu, 15 Jul 2021 13:14:36 -0400 Message-ID: To: saag , int-area , IPsecME WG , sfc@ietf.org, tls , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000b20d6d05c72c9ba9" Archived-At: Subject: [IPsec] Heads up on Netdev conf 0x15 - not too late to attend! 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, 15 Jul 2021 17:15:01 -0000 --000000000000b20d6d05c72c9ba9 Content-Type: text/plain; charset="UTF-8" Hi, For those that have not already attending Netdev, Netdev conf 0x15 has been running since July 7 but it runs for 3 weeks but the talk sessions don't start until Monday. As usual a lot of IETF relevant talks. See: https://netdevconf.info/0x15/accepted-sessions.html The fee is USD $50. Students(proof required) are 50% off. The first 2 weeks was keynote, workshops and tutorials. You can replay all the sessions you missed by entering the conference platform (registration required). The keynote was by Hari Balakrishnan, see: https://netdevconf.info/0x15/session.html?keynote-balakrishnan On Monday as well there will be an industry perspectives panel on smartnics which will involve 6 vendors and an industry veteran moderating the session. For registration go here: https://netdevconf.info/0x15/virtual.html Yours, Daniel -- Daniel Migault Ericsson --000000000000b20d6d05c72c9ba9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

For those that have not= already attending Netdev, Netdev conf 0x15 has been running since July 7 b= ut it runs for 3 weeks but the talk sessions don't start until Monday. = As usual a lot of IETF relevant talks.
See:=C2=A0https://netdevco= nf.info/0x15/accepted-sessions.html

The fee is USD $50. Students= (proof required) are 50% off.

The first 2 weeks was keynote, worksho= ps and tutorials. You can replay all the sessions you missed by entering th= e conference platform (registration required).

The keynote was by Ha= ri Balakrishnan, see:
https://netdevconf.info/0x15/ses= sion.html?keynote-balakrishnan

On Monday as well there will be a= n industry perspectives panel on smartnics which will involve 6 vendors and= an industry veteran moderating the session.

For registration go her= e:
https://netdevconf.info/0x15/virtual.html

Yours,= =C2=A0
Daniel

--
Daniel Migault
Ericsson
=
--000000000000b20d6d05c72c9ba9-- From nobody Thu Jul 15 10:47:31 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 62FFA3A14A5 for ; Thu, 15 Jul 2021 10:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hpe.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 dJDdJz2M0JLa for ; Thu, 15 Jul 2021 10:47:24 -0700 (PDT) Received: from mx0b-002e3701.pphosted.com (mx0b-002e3701.pphosted.com [148.163.143.35]) (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 E46C13A149C for ; Thu, 15 Jul 2021 10:47:23 -0700 (PDT) Received: from pps.filterd (m0134425.ppops.net [127.0.0.1]) by mx0b-002e3701.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 16FHiYYi025346; Thu, 15 Jul 2021 17:47:22 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hpe.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=pps0720; bh=84Hu1OyWtfkXnZ0I3bgpnAwl77evabJl8HddlxND68w=; b=cuf1/3qw4qHoMHlsx/M7Vd30kpUZJhH1wdaUaYb+qiVX9lJkydAioVt1yJpbv11nRuEp VRgu75IIG/ip4eBFL9+mJlaUurfWLTFlQayErTSOYvc/4Nk8+Qk7TFHFj8mYi46Xv7+9 6Cmr6bCMAom613ChI96duPxODHpQCqAJoR5U7fN74my8b6Qj7FjrlWYaTAODIngY8Q3Z JpEv/kOfCUvrwxh2iUAbikqlhyrB6S2SY3obObb5B3BsTqmzAcdtoFZQywJCdi8puda0 KT8CKIHYmFKIw/wQ6EuwfRV92ARkfcow0tinYOqlX9f75fPPUmIF0+d1lTg+ZqXxySqn NA== Received: from g4t3427.houston.hpe.com (g4t3427.houston.hpe.com [15.241.140.73]) by mx0b-002e3701.pphosted.com with ESMTP id 39th7mn5c7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Jul 2021 17:47:17 +0000 Received: from G9W8454.americas.hpqcorp.net (exchangepmrr1.us.hpecorp.net [16.216.161.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by g4t3427.houston.hpe.com (Postfix) with ESMTPS id 39B0B57; Thu, 15 Jul 2021 17:47:16 +0000 (UTC) Received: from G9W8453.americas.hpqcorp.net (2002:10d8:a0d3::10d8:a0d3) by G9W8454.americas.hpqcorp.net (2002:10d8:a104::10d8:a104) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Thu, 15 Jul 2021 17:47:16 +0000 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (15.241.52.12) by G9W8453.americas.hpqcorp.net (16.216.160.211) with Microsoft SMTP Server (TLS) id 15.0.1497.18 via Frontend Transport; Thu, 15 Jul 2021 17:47:15 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BoykPIxzpmfWXKFYlNslP7V+3dhi/dyYkd9Nk6kgou8ilQiBcOKDl1lLrauJMPytxiR9Nr/GRozSHg4v7moRKRls6k7CnI9ShjwWaJ9Q+y+nSR3XGmHZI4i5jiBShhtkJZSCSnPrUBrpAc0mGKc8MWmpmc3sA+Q3ljkJP7d7aLcmYFh8vssGrNVNge4Bx+MoO0FXlUOHlxZ85fgmdmhVIIzWCDedX2HgIVmX0Ok5RkT2UCBf3JqSKR/WBizTvwW76lbhusR60pL82Gk8VrGPoA5KVngURxC1B0FULgE8TsAL0OtF81l+KBgdpmu5KPBBROwMuNl7nExm1EPUv9DhoA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=84Hu1OyWtfkXnZ0I3bgpnAwl77evabJl8HddlxND68w=; b=XHkvxNo53P4jMrJ183Pw+2U6Kdu3UJpUtZ/ODgHfS0DslLLGlteUk0C0mByYpqJBAUlpj1d4CJvOa8UObaNSQKPPfFHCsatsneK6nv+FxkTvicraeIlKxr6GVoZbVhUp0D9B2LBmmesIxVUgqGdrJiUGmXdaRicaOvdt8cvaVCZaPTkTv4kLgtD3B18TLVNv3U/hBHNaG4KuTctPPD7d93ZNLeTjtw3rQd6Ik3Gfepon0P6WmuH8VRDFNeUsvEj2tjSGI1Zq+sR4A7KeKLCIsOSi5aOpoS4SqhHVp9i13EEMXLkh016oAG8cKgMqkEB3Z+Cay9f35fUw3xst8Xvoyw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=hpe.com; dmarc=pass action=none header.from=hpe.com; dkim=pass header.d=hpe.com; arc=none Received: from CS1PR8401MB1192.NAMPRD84.PROD.OUTLOOK.COM (2a01:111:e400:7507::23) by CS1PR8401MB0837.NAMPRD84.PROD.OUTLOOK.COM (2a01:111:e400:750e::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.21; Thu, 15 Jul 2021 17:47:14 +0000 Received: from CS1PR8401MB1192.NAMPRD84.PROD.OUTLOOK.COM ([fe80::a4ff:aeb9:d100:6536]) by CS1PR8401MB1192.NAMPRD84.PROD.OUTLOOK.COM ([fe80::a4ff:aeb9:d100:6536%9]) with mapi id 15.20.4331.024; Thu, 15 Jul 2021 17:47:14 +0000 From: "Bottorff, Paul" To: Tobias Brunner , Valery Smyslov , 'Tero Kivinen' , "antony.antony@secunet.com" , 'IPsec' Thread-Topic: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07 Thread-Index: AdciaiROLLoGnn3oQyW5+9ys0PMxKgJRErFpANOS/JYCNRDTH6tGNXFQq2XEr5DWKZkDwNOtc7uA//9oygA= Date: Thu, 15 Jul 2021 17:47:14 +0000 Message-ID: References: <20210331103220.GA21137@moon.secunet.de> <24678.19440.553333.890224@fireball.acr.fi> <036401d72786$91047b90$b30d72b0$@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: strongswan.org; dkim=none (message not signed) header.d=none;strongswan.org; dmarc=none action=none header.from=hpe.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f66d2d39-352a-40e4-e28c-08d947b894d8 x-ms-traffictypediagnostic: CS1PR8401MB0837: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gwjdHgIYB5alwYJXjxDfFwTtAiymBHRL/udPGTFR8zF2IKwGOKPufnqeDUe5f3Bbf8JTPb4U5nnmLcIr8fUrqD0wqgfh7gHjxqWYNcC/lyKScHjp3AfcgB4ZJaNS1nLfmDn57bSIGAPKm9gC5KpAn3lhDu5bfJI5ySQ0Yvz++440eua1x8D6dY5YOXzjUYIGADz8/R8HPTV4HqWMkD3sKXUHfVZfExTM+QEacCCXNwpqouTqhnfff1A2Rkw4l8ynjqAjIo/FZ7cPnMHQJGbIj1771yxH/7H787g6lcnbujt7NDWA4NoFvo+1Uu3UmqATK1xhOvXoxYSLu+ThVZdlohDwxvNlte6F3bJn3bzK1jukrKqFm2z0/BblTCSSUNZSj4cQd4fGw5XSp0iXVgTmp+0dF0mdn0MHHx5+uj6xx2ji+MEk5s9Kc4v+gSBniTajy7mX/blH1JXQBOcJOjUOyNwiNWcsiCcxtiDjoIfVMhcaB8W4aJIeU/dpkjQE5Md1c+XgMLZznj782OYhZS5qRc9l6ft9M0/gpoV9nVVsIL2AwEJp87ds96bqFPyOGY6217pEFVMosCuwXOtjrGmHh301sAGP7QkpksyeR7G1At6VOyktOLX8oP6Miu1IaKbx1b55uHKcTER9Eyu5JYcwlVhI1qh0tP/NcN305pprkcrrd3ZrVRXuIuCKd/jyqWML4de8Xl7WRUg+4fVJgG0iOQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CS1PR8401MB1192.NAMPRD84.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(2906002)(122000001)(76116006)(33656002)(52536014)(186003)(64756008)(66556008)(38100700002)(66446008)(66946007)(7696005)(478600001)(66476007)(8936002)(8676002)(6506007)(55016002)(55236004)(86362001)(316002)(26005)(53546011)(83380400001)(9686003)(71200400001)(110136005)(5660300002)(38070700004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?NDIwSkQ4dHkwU2FKdm1lelhpb0VVamRuZUN3ZUJySm91YWVBUGFETFVyWEtW?= =?utf-8?B?VnB0NUlybzA0WDhPbUJ2cXFvL3MvZEJ4a2dmeXdjWm5ZVkNhNm5zMTVSa3BV?= =?utf-8?B?S1J1aUR2cWdSN0kzT0lPSUlmK21KZUVJUmF6MFBlcFZPVDAremhNeURiL0dz?= =?utf-8?B?dHkxV2dZNW55bStHVGNOaVJmaHJOcWsvSG13aTRleHNDM2NYS0FpUFZoNDlJ?= =?utf-8?B?OUxGUnRPWUJxZ1VIbllJN0hncnVnNlBENDFkR2tYdVJ0dCtHTFhldUh1b284?= =?utf-8?B?dEtzUDFpR0VReU85Q25DUzErQmNEZ25IWExBT3N5dW8vSXp5b0NHK3FMY2FX?= =?utf-8?B?akkvRkU0U0EzeDBVVEFaUzhCRDN3ejhPRkFUUzF3T3B4aXkza0VhdjI5Njlp?= =?utf-8?B?dkM0TDhMN2w1TDBxTW42alBjT1lvazcvRDNVNnR2cXQzSmloeHBHbWlRRkRB?= =?utf-8?B?dWNJYW9SRjN4L3M5Y2RQODRmcjAvN2lRL0ozeGhxQ21EYXNaMDNyOTMxMkEz?= =?utf-8?B?cUp0dDk4UXQ0cElUc0daNVpKVk54NGh2bzVibU9SVCtJMjdiQmswOFRkQUhG?= =?utf-8?B?RTFLYWpkSndoTDZnTmlMVlRJWTFLMS92QThWTzI0bVVDMld3UHdjcDBMNGVI?= =?utf-8?B?dXgzWTljaGtjLzRhRFN1YU94aitiMjcwamRBWi9XL25MRmtuT0FWajNQc1Bw?= =?utf-8?B?MTlnek5ubW0vK1RhRUt5d2VyeTYyK2phRyt4Vks5a3EvWlhOWnlKVHA5N3Ur?= =?utf-8?B?TVhQdVV2TkV3aDJvRzFBT011enByd2w4N0JZUllZZ2ttWEM4UURjS0dxNHFI?= =?utf-8?B?clFoVEJZYXhFbGJHQzlpb1pTZm51aDgvQjcraTY5d0FzcnlZN2QzT3liQjFI?= =?utf-8?B?ZWlLcmszS2xuZ0pxQ0JKZGRIdzFtQ3BYT3ovT2JhTzQ3TmM2Z2ZYL2NtS0xt?= =?utf-8?B?M0RmYWRXZVhsazdMakFsSHNoRzAwZ0p0bTUvSDl0d3VRR0dzYUoxSW43ZWVw?= =?utf-8?B?dEEvVlpwTEhYRHlkWGgxejM2VmRyZUlIWTBINSsvRld6b3RReUZwSGVsNGdW?= =?utf-8?B?TGl0ajdkZmZRUlVUY2ZZV0l4UzNGWEdFVXVTU3pDOXF3ZHYzMGVKR1ZUWWVm?= =?utf-8?B?NDkwdlBjNlRqOVE5MUdzUTcrbDhxdklXZTl3eVE3RCs5YmFIdld4aG10UnVU?= =?utf-8?B?T2RVMEpNS3A4Z1VtbGR0SmIrKyszVGduSXI1NWUrTzIzNVRTbWJ1K0hudXFM?= =?utf-8?B?ZVBSaFA5SVBPdWZjOFVNZjcwWmEvMUw0MGM4RVJBeitUTjhCMDBGSEQ3TmJN?= =?utf-8?B?TXhxQmhTNW1KbTNTZkpjK2s5T2F3bzVnZ0hCaks3OXlaNWt5elB5b1BpdGRq?= =?utf-8?B?R2RxSjY5d3RVNFYwUkRITFVhbU9ia0JFWExLWXVhK2RDMHZJdWgrdkxuQlRC?= =?utf-8?B?Z1FSdjBBaFQwREhTdVhueHYyaWlkaW4zaG9mT1l0YWFXaTFnSFozZnlQeGc5?= =?utf-8?B?alF6Y0R2czZGTHg1dHhBMlU3UWNjREpoeGJoWWZzeVRKYmJKV3pYVk1iZlVp?= =?utf-8?B?ZzlrVkwzcy9LbGpTa1lVbnlPc1ZwdXJuNEpQRnBvZlhBTXdtSE5vUk1OeWRR?= =?utf-8?B?UGtDNnN2MjUvUGxldDArcWV1cktOVlFXQU9VNHRRa1JqUmlQNjd6VnY3MHVE?= =?utf-8?B?TlRReStSenpoN0JOV3phTXMzaTdXTDh4MlpkVndZSnN3cStXVzlwRGZVNzRw?= =?utf-8?Q?ZWOm/yOx+6sffWQfTEFBrshPAxsjEKOi7ZQbVS/?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CS1PR8401MB1192.NAMPRD84.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: f66d2d39-352a-40e4-e28c-08d947b894d8 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2021 17:47:14.4862 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ruMDB89CDiB8imBqK/Xa1QxLSPFJN4H9cMJ6OKLnLB9F76pnKXivQ7WbvxDJhMK0uyAjps4evnJ0VE29oyzdOQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CS1PR8401MB0837 X-OriginatorOrg: hpe.com X-Proofpoint-GUID: 1BUIfuWnip2azyprapiDFQJShTHY2xTC X-Proofpoint-ORIG-GUID: 1BUIfuWnip2azyprapiDFQJShTHY2xTC X-HPE-SCL: -1 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-15_10:2021-07-14, 2021-07-15 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 mlxlogscore=999 phishscore=0 malwarescore=0 lowpriorityscore=0 adultscore=0 bulkscore=0 mlxscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107150121 Archived-At: Subject: Re: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07 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, 15 Jul 2021 17:47:29 -0000 SGkgVG9iaWFzOg0KDQpUaGUgcG9ydHMgdXNlZCBmb3IgSUtFIHBhY2tldHMgd291bGQgbm90IGJl IHJhbmRvbWl6ZWQgc2luY2UgSUtFIHdvdWxkIG5vdCB1c2Ugc291cmNlIHBvcnQgZm9yIExCIGFu ZCBzbyBzaG91bGQgYmUgc3RhYmxlIGF0IHRoZSBOQVQuDQoNCkNoZWVycywNCg0KUGF1bA0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogVG9iaWFzIEJydW5uZXIgPHRvYmlhc0Bz dHJvbmdzd2FuLm9yZz4gDQpTZW50OiBUaHVyc2RheSwgSnVseSAxNSwgMjAyMSAxOjM2IEFNDQpU bzogQm90dG9yZmYsIFBhdWwgPHBhdWwuYm90dG9yZmZAaHBlLmNvbT47IFZhbGVyeSBTbXlzbG92 IDxzbXlzbG92LmlldGZAZ21haWwuY29tPjsgJ1Rlcm8gS2l2aW5lbicgPGtpdmluZW5AaWtpLmZp PjsgYW50b255LmFudG9ueUBzZWN1bmV0LmNvbTsgJ0lQc2VjJyA8aXBzZWNAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW0lQc2VjXSBkcmFmdC14dS1pcHNlY21lLWVzcC1pbi11ZHAtbGItMDcNCg0K SGkgUGF1bCwNCg0KPiBJbnN0ZWFkLCB0aGUgcmVzcG9uZGVyIHNob3VsZCB1c2UgdGhlIHBvcnQg cmVjZWl2ZWQgYnkgdGhlIHJlc3BvbmRlciBpbiB0aGUgSUtFIGV4Y2hhbmdlcy4NCg0KTm90ZSB0 aGF0IGlmIHRoZXNlIHBhY2tldHMgaGF2ZSByYW5kb20gc291cmNlIHBvcnRzLCB0aGlzIHdpbGwg b25seSB3b3JrIGlmIHRoZSBOQVQgaW1wbGVtZW50YXRpb24gcGxheXMgYWxvbmcgb3IgdGhlcmUg aXMgc3RhdGljIHBvcnQgZm9yd2FyZGluZyBjb25maWd1cmVkLiAgTkFUcyBtaWdodCBmaWx0ZXIg aW5ib3VuZCBwYWNrZXRzIGZyb20gZW5kcG9pbnRzIHRoYXQgZG9uJ3QgZXF1YWwgdGhlIElQL3Bv cnQgdG8gd2hpY2ggdGhlIGhvc3QgYmVoaW5kIHRoZSBOQVQgb3JpZ2luYWxseSBzZW50IHBhY2tl dHMgd2hlbiB0aGUgTkFUIG1hcHBpbmcgd2FzIGNyZWF0ZWQgKGFkZHJlc3MgYW5kIHBvcnQtZGVw ZW5kZW50IGZpbHRlcmluZyBpbiB0ZXJtcyBvZiBSRkMgNDc4NykuICBJIGd1ZXNzIHRoZSBzYW1l IGNvdWxkIGhhcHBlbiBpbiBzY2VuYXJpb3Mgd2hlcmUgdGhlcmUgYXJlIG5vIE5BVHMgYnV0IHJl c3RyaWN0aXZlIGZpcmV3YWxscyB0aGF0IGJsb2NrIHRyYWZmaWMgZnJvbSBlbmRwb2ludHMgdG8g d2hpY2ggdGhlIGhvc3QgYmVoaW5kIHRoZSBmaXJld2FsbCBkaWQgbm90IHNlbmQgdHJhZmZpYy4N Cg0KUmVnYXJkcywNClRvYmlhcw0K From nobody Thu Jul 15 23:51:41 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 DD92F3A285F for ; Thu, 15 Jul 2021 23:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=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 O2nQcfmMLkcf for ; Thu, 15 Jul 2021 23:51:37 -0700 (PDT) Received: from mail.strongswan.org (sitav-80046.hsr.ch [152.96.80.46]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 805893A285E for ; Thu, 15 Jul 2021 23:51:36 -0700 (PDT) Received: from [IPv6:2a01:8b81:5407:c100:1167:3b51:5981:7a21] (unknown [IPv6:2a01:8b81:5407:c100:1167:3b51:5981:7a21]) by mail.strongswan.org (Postfix) with ESMTPSA id 4A1FD40158; Fri, 16 Jul 2021 08:51:34 +0200 (CEST) To: "Bottorff, Paul" , Valery Smyslov , 'Tero Kivinen' , "antony.antony@secunet.com" , 'IPsec' References: <20210331103220.GA21137@moon.secunet.de> <24678.19440.553333.890224@fireball.acr.fi> <036401d72786$91047b90$b30d72b0$@gmail.com> From: Tobias Brunner Message-ID: <7cd40215-563d-9860-62fa-4110f1bd3895@strongswan.org> Date: Fri, 16 Jul 2021 08:51:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07 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, 16 Jul 2021 06:51:40 -0000 Hi Paul, > The ports used for IKE packets would not be randomized since IKE would not use source port for LB and so should be stable at the NAT. I was not referring to the IKE but the ESP packets sent by the responder to the natted IKE port for LB. Wasn't that what you were proposing? Regards, Tobias From nobody Fri Jul 16 11:05:11 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 0011E3A3F7D for ; Fri, 16 Jul 2021 11:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hpe.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 JKtwsUU9bUf6 for ; Fri, 16 Jul 2021 11:05:04 -0700 (PDT) Received: from mx0b-002e3701.pphosted.com (mx0b-002e3701.pphosted.com [148.163.143.35]) (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 2AA953A3F77 for ; Fri, 16 Jul 2021 11:05:03 -0700 (PDT) Received: from pps.filterd (m0134424.ppops.net [127.0.0.1]) by mx0b-002e3701.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 16GHsHix013135; Fri, 16 Jul 2021 18:02:48 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hpe.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=pps0720; bh=HJFAyXTfE4l/dqHG62/3Zo30BzASo/RI502kq2XdcGc=; b=Ohcispu2uHmXJkcDUPGuTuk4k6MKp4PghICRHZALeKFgvB97NEnh33TrnHds4Dz1Jr0v 1dUFoPufmg77TeyuLY7MRMWLI4utx/RqwjP+w5H9yEN5LmQoInuwkqTTeLbprgxDvpG/ GKmvQh44yRQYpzxBCPgoV/9wfWu56CEbsqs1NDlGxnyVKiaIxfr+DYHrgqVK2mlKZhqO FpnvPS8B81IU/JYVI2L5RSKidvKfXCSYBrVrBm16loJutjuTQCL/zddt9RDD25mvQvq1 nSZYFYhAY9J79CdAGGDobrsTYUYOGxfbqLJ7hXQPc+FzymPON1BouYPeA7shKtom7KLu Uw== Received: from g9t5008.houston.hpe.com (g9t5008.houston.hpe.com [15.241.48.72]) by mx0b-002e3701.pphosted.com with ESMTP id 39tw81gawg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 16 Jul 2021 18:02:48 +0000 Received: from G9W8455.americas.hpqcorp.net (g9w8455.houston.hp.com [16.216.161.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by g9t5008.houston.hpe.com (Postfix) with ESMTPS id C00244F; Fri, 16 Jul 2021 18:02:46 +0000 (UTC) Received: from G4W9120.americas.hpqcorp.net (2002:10d2:150f::10d2:150f) by G9W8455.americas.hpqcorp.net (2002:10d8:a15e::10d8:a15e) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Fri, 16 Jul 2021 18:02:46 +0000 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (15.241.52.13) by G4W9120.americas.hpqcorp.net (16.210.21.15) with Microsoft SMTP Server (TLS) id 15.0.1497.18 via Frontend Transport; Fri, 16 Jul 2021 18:02:46 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LrDUjnpHuLI3JIIJjK+Rgli1o65edTx2lCh5znVCx+v4Gz+WLumW0OjSEo6ATlbV8GoMPdiGkOI4JEU4QHq/DjWVenx1db5oag22b+fKf5MRY+9R/6MGibGPFRSziARyIVizxdEsPY3XYaBblWiRxCHkxWk4fQFRbMTxzL4WYWcNhFQOUOYJtfZLztFIo0nfxIxFbwUObDkN1Rr+xeuGY+tT+gS3RgEGynXutb7H5T+/nvtIF/hh+wCGmSz4BkGqESaPiFpeshMeUaQK8VYjOrqkCGUXqsXgatVcJjHR6HOvENMVLz9t/sYWn0NJfJfQQVojJHzlgSm6o02g/nFpTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HJFAyXTfE4l/dqHG62/3Zo30BzASo/RI502kq2XdcGc=; b=bHkRpl1R81HXu+IcXjit4lbVoFbKntLsACIhMsXBxpUoGyxqsRf9ojgqEiM6D0WkJUaQC7OllYFVvHjlQe9XuJj7fnKeJFSCI1GPp7qfCYQqW6emXQqINHuObuBXZgHYx68WkXK0K11F/sPmQEzeaRH4lfFMCeaz3CB4JQEZi4YGYphnXJA5Lh8MDV7I3GAq3RsLsa6WEdaCdNu1XEWM4jlChgOLoXIxxh7dKE9+1gYDbupFWiWgR9wCEHAj6srCL0xNcR+kl1+kgUce4ss4R2TLAE0fMFMZClnAudfRUo/K+l7GARozayjqCM3w7APS5gK6NZVAFHs4ncChtE24sg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=hpe.com; dmarc=pass action=none header.from=hpe.com; dkim=pass header.d=hpe.com; arc=none Received: from CS1PR8401MB1192.NAMPRD84.PROD.OUTLOOK.COM (2a01:111:e400:7507::23) by CS1PR8401MB0901.NAMPRD84.PROD.OUTLOOK.COM (2a01:111:e400:750f::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.21; Fri, 16 Jul 2021 18:02:45 +0000 Received: from CS1PR8401MB1192.NAMPRD84.PROD.OUTLOOK.COM ([fe80::a4ff:aeb9:d100:6536]) by CS1PR8401MB1192.NAMPRD84.PROD.OUTLOOK.COM ([fe80::a4ff:aeb9:d100:6536%9]) with mapi id 15.20.4331.026; Fri, 16 Jul 2021 18:02:45 +0000 From: "Bottorff, Paul" To: Tobias Brunner , Valery Smyslov , 'Tero Kivinen' , "antony.antony@secunet.com" , 'IPsec' CC: =?utf-8?B?5b6Q5bCP6JmO?= , "Shraddha Hegde " , Mahendra Maddur Puttaswamy Thread-Topic: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07 Thread-Index: AdciaiROLLoGnn3oQyW5+9ys0PMxKgJRErFpANOS/JYCNRDTH6tGNXFQq2XEr5DWKZkDwNOtc7uA//9oygCAAgxigP//WMdw Date: Fri, 16 Jul 2021 18:02:45 +0000 Message-ID: References: <20210331103220.GA21137@moon.secunet.de> <24678.19440.553333.890224@fireball.acr.fi> <036401d72786$91047b90$b30d72b0$@gmail.com> <7cd40215-563d-9860-62fa-4110f1bd3895@strongswan.org> In-Reply-To: <7cd40215-563d-9860-62fa-4110f1bd3895@strongswan.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: strongswan.org; dkim=none (message not signed) header.d=none;strongswan.org; dmarc=none action=none header.from=hpe.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dce91c14-914e-4fc1-b095-08d94883e9fa x-ms-traffictypediagnostic: CS1PR8401MB0901: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xz0XkkH1Etk6R1hkVa5x6my6KfVl60Z4QtFBxsSDN3KjeN2sIKkzyM7hAjCgRXLTDfb0V4prot/SvwpTQ+qdFyBhvUyy8WlgBK7Ot872DVerM7X9Y+rDYrHVEWfayiVeexW/7vp5mnNFf9ePd3JH92c2+YKGaBvWPDCBhF6mrF7lldVNC5oqeouTBaz+R3QFnQQXKuP0shNTzlKvusdP0IO9D99vNSZ8qAdvgKbVizn2WBT3Wo3RoGew8yqW3dNhxueRCAYGxazM6E/JllY3Nu4z8Ejlwip4gW9aZ/oZ8X2F+l4MiJ1HmHsX7inEdyGQ3yH+fOrcLHLxr/vPOQj1R8wa8w/JRKMi1xnyYj4GbSS2KJ2QrqmfKdUyKdx8pq7+FbLH9lakSoXWvfCeRKvSaR8JQQgwavjotD8+utKq5x/6np4ZMAirD+dwJoMtfvv3hzG3+jCHDN4uzHoiJYmJRzZkUaUv+fKg0Bt1QfAymudy47Yk+9Z82Y5VeBXrri7GQAvnKqEnxne/PlB1k4eBJTa2dZGcaT0luywsEkbLbc159WYWvwbN4LEUuOJi3EQf1wvZFgoZ++CyXDoC+PT6VOLa1+1TMY8AnhIO0xL0OWZDHwnDrHRRuLR1TmRENTSse8MEfc3KDhk3lG4iAxCD2ZyJaW9YcDtbG/n/dnHHwvf8isB2+8OtPVtFtkCXzDl7SyDGaE6mXXXYAR9a3SVRjw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CS1PR8401MB1192.NAMPRD84.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(376002)(39860400002)(366004)(346002)(396003)(136003)(53546011)(6506007)(7696005)(5660300002)(55236004)(2906002)(52536014)(54906003)(38100700002)(122000001)(8936002)(8676002)(4326008)(71200400001)(66476007)(186003)(83380400001)(316002)(478600001)(110136005)(33656002)(66574015)(26005)(55016002)(86362001)(76116006)(64756008)(66946007)(66446008)(66556008)(9686003)(38070700004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Z0c4Y21STE5YMFY5OEJUdVY3bFBYc2I5QXlnOE00N2VsU1Zhbyt0NVQrSDli?= =?utf-8?B?Vll5T0JqYldxaksvYm9BV0l6RjUvY01ycHp4WFZvTkE1ZU5FS05UTnhXeGR3?= =?utf-8?B?amZpWkpySkJNQlJNV0dXSW1WRlhydTdYdDhUV1ovWFBIc0loODlwYTVHckd3?= =?utf-8?B?Q2RFejcvOVIzTmJNZlNBYzEwRE9zTlpCQ3RoeGwvWlM0WlpYWnZvVFI1d0NR?= =?utf-8?B?WTNlOHBYc0dMRGVOQXF4NE5mZjArRFZCdjcybGl3R1M2MGpsUERzQ0RLSnFw?= =?utf-8?B?OUtsamdwYlpzeXZmRDlBZ3VuVDBoVkw2Vmt2dmhmcGxPTDlMNU5seHM2by9B?= =?utf-8?B?bU1heTBNN1RGdE1yQk9mdElpNy8wTkRWdHRDMlNWV2tpQ1ZCQUd3bmR3SDll?= =?utf-8?B?ZCsxcXdFVzJMdDYvQzBobXBvTDk4eU1VRzhxOUlIbDY5Y3VwY1VqaEg5UTR4?= =?utf-8?B?N0wvMzNINkIvL09qdS84dzUyVThVMU1pdHhYOVJXY0hTcCs2T084eUhlSzV6?= =?utf-8?B?cGo1aitWbFc4YlZkNlcyOS9oMTY3SUE3L3ZqWjFJOWNLSytKczh2NFZ3SXZT?= =?utf-8?B?bTZ4bzZVdW5Ycnk5WmY3Wk0wNlRVRkU4VzBaYjRSb215dURYTURZZTVoWFlM?= =?utf-8?B?YmxQZVc1S0hHaWdLMEsrQnF0VEZLeldEK01ZY3l6WWxxMjZGNjZobkpUYlM4?= =?utf-8?B?YzZUNmxva2JyNGlpc2V6cVFMdHVtdFhoYW9kK3o5VFNhZUFIb25RdEgvL2Nx?= =?utf-8?B?VXlSd0tISFV1TUsxTUVpVGRTTFVNNW1sTkNjYmQ4TldJU3c2RjcvWHVGQ3pY?= =?utf-8?B?a2FaMy9NZ0w5RVZwS0puRWFPeXNJUGpFSjJiQ1JvMDk0cHpNMm5LWE9EVjhH?= =?utf-8?B?bjJuS0dEOXFnTTFna2llRlljN2I0YS9hYytyc0pDYTlEYk5SMTc0UE52RjVw?= =?utf-8?B?T0JXV3BIWGxmZzZYT2hOWWZ2bXk1MnYrSFFjM21FNlRBUlRrZ0NWZ29nczlW?= =?utf-8?B?Uk5hQVJqazh3cVcrYS83NFFTbjRjYUdLaGdMNjhmeVdPcEZCMmN1S0FNcENp?= =?utf-8?B?WHZDVWhxcTU2TVVRbHIvUWNaV0hQdUowSUNUcVVGTWdzMGFMM0cyRlZTMHVz?= =?utf-8?B?K29LUUJFM2g4TVJEWDJNb2ZmaVlkYTgwaG9RTHdqa205Z1BmRHlNSm5qam5n?= =?utf-8?B?cTBQenpDQ3pJWlZyMGdrNVhTTWo0WEo5azRIK2VWbG1Fdlo0T2RFcFlncWFH?= =?utf-8?B?N3R4NHJiOEV4ajJwb2NXOEc1RUpFOGlSRDJjNzZPZVFWaldQczVaQVJsZ2w2?= =?utf-8?B?dGF5WTRENFdiS2lzVG5pNUY2b2RXQXdVYm9RZWlxMC9WV3BMK2dQV2NUUUJV?= =?utf-8?B?UWNhNG85KzVROG83QTVFL0tUdTRoUUE1VmVpUmgvKzArVkFhaXFkd3MyRDAz?= =?utf-8?B?VkhNSmNSaE1vSlJrZmdKMVRUK3U2L3ZYWEx3cmszMFdFSzdoYlF2VkxWejI0?= =?utf-8?B?eE45bUdRbklxRFVWdk1leml3VVozRUd1bDBiK3RpZlpKb240SWc2ZjVyU2xC?= =?utf-8?B?Z3NOMCtoSDFxL081R1pLQjdHT0tqbUZjV0YzaWdqWHRRQlBBYTVLbjVXTjFv?= =?utf-8?B?Z2ZhT0x1WTdHcnZXN0NZN244dU9tdG0vV2lya3lBcjloM0VuZ2NpOFkrVWlX?= =?utf-8?B?ajhwQkUrT1JpcTNmemR0YzRIOEc2RkNFMWMyZDFOUi9oSHB0N05xQldDZTNY?= =?utf-8?Q?U7YfuagrYoiUVnAZVpBybWlgzWMKVD4BDVvjd+X?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CS1PR8401MB1192.NAMPRD84.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: dce91c14-914e-4fc1-b095-08d94883e9fa X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2021 18:02:45.1362 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Kl0zisuEQPQgS3c6ZYV6LrvLRj3qm19g/uvQ3Z39nbfl6GLxvt7SlO8M8v9T4ArSt55PMyngTTb63RwrUlIyRw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CS1PR8401MB0901 X-OriginatorOrg: hpe.com X-Proofpoint-GUID: hSA8dYOFCNfL9_QophCgI0Jwq-B_e2Yu X-Proofpoint-ORIG-GUID: hSA8dYOFCNfL9_QophCgI0Jwq-B_e2Yu Content-Transfer-Encoding: base64 X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-HPE-SCL: -1 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-16_06:2021-07-16, 2021-07-16 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 lowpriorityscore=0 mlxlogscore=999 adultscore=0 priorityscore=1501 impostorscore=0 suspectscore=0 bulkscore=0 malwarescore=0 spamscore=0 clxscore=1011 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107160110 Archived-At: Subject: Re: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07 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, 16 Jul 2021 18:05:09 -0000 SGkgVG9iaWFzOg0KDQpTb21laG93IEkgdGhpbmsgd2UgYXJlIG1pcy11bmRlcnN0YW5kaW5nLiBQ bGVhc2UgZXhjdXNlIHRoZSBsb25nIGludHJvZHVjdGlvbiB0byBhbnN3ZXIgeW91ciBxdWVzdGlv bi4NCg0KQ29uc2lkZXIgYW4gSVBTRUMgaW5pdGlhdG9yIHNpdHRpbmcgYmVoaW5kIGEgTkFQVCB0 YWxraW5nIHdpdGggYW4gSVBTRUMgcmVzcG9uZGVyIG9uIHRoZSBJbnRlcm5ldCAod2l0aGluIGEg REMpLg0KDQpUaGUgaW5pdGlhdG9yIHdpbGwgc3RhcnQgd2l0aCBJS0UuIFRoZSBJS0UgcGFja2V0 cyB3aWxsIG5vdCBiZSBMQiBhbmQgc2luY2UgYSBOQVBUIHdvdWxkIGJlIGRldGVjdGVkLCB0aGUg SUtFIHBhY2tldHMgd291bGQgdXNlIHNvdXJjZSBhbmQgZGVzdGluYXRpb24gcG9ydCA0NTAwLg0K DQpBZnRlciBJS0UgZXN0YWJsaXNoZWQgdGhlIFNBLCBsb2FkIGJhbGFuY2luZyB3aWxsIGJlIHVz ZWQgd2l0aCBFU1BpblVEUCBwYWNrZXQgZXhjaGFuZ2VzLiANCg0KQm90aCB0aGUgaW5pdGlhdG9y IGFuZCB0aGUgcmVzcG9uZGVyIGNhbiBleGNoYW5nZSBFU1BpblVEUCB3aXRoIExCIGFmdGVyIHRo ZSBTQSBpcyBlc3RhYmxpc2hlZC4gRm9yIEVTUGluVURQIHdpdGggTEIgdGhlIHNvdXJjZSBwb3J0 IHdpbGwgYmUgdXNlZCBmb3IgZW50cm9weS4gVGhpcyBkb2VzIG5vdCBuZWNlc3NhcnkgbWVhbiB0 aGUgc291cmNlIHBvcnQgaXMgcmFuZG9tLCBob3dldmVyIGRvZXMgbWVhbiB0aGUgc291cmNlIHBv cnQgbXVzdCBjb3ZlciBhIHJhbmdlIG9mIHZhbHVlcyBzdWZmaWNpZW50IHRvIHByb3ZpZGUgdGhl IHJlcXVpcmVkIGxldmVsIG9mIGVudHJvcHkuIERyYWZ0LXh1LWlwc2VjbWUtZXNwLWluLXVkcC1s YiBkb2VzIG5vdCBwcm92aWRlIHNwZWNpZmljIGd1aWRhbmNlIG9uIGVudHJvcHkgdmFsdWVzLCBo b3dldmVyIGZvciBOQVQgaW50ZXJvcGVyYWJpbGl0eSBpdCBpcyBkZXNpcmFibGUgdG8gbGltaXQg dGhlIG51bWJlciBvZiBlbnRyb3B5IHZhbHVlcy4NCg0KQXQgYW4gSVBTRUMgaW5pdGlhdG9yIChi ZWhpbmQgTkFQVCkgdXNpbmcgZHJhZnQteHUtaXBzZWNtZS1lc3AtaW4tdWRwLWxiIHdpbGwgZ2Vu ZXJhdGUgTEIgRVNQaW5VRFAgcGFja2V0cyB3aXRoIHRoZSBlbnRyb3B5IHZhbHVlIGluIHRoZSBz b3VyY2UgcG9ydCBhbmQgYSBuZXcgZGVzdGluYXRpb24gcG9ydCwgaG93ZXZlciB0aGUgdXNlIG9m IGEgbmV3IHBvcnQgdG8gZGVzaWduYXRlIExCIGNvbXBsaWNhdGVzIHRoZSBzaXR1YXRpb24uIElu c3RlYWQsIGlmIHdlIGNvbnNpZGVyIGJvdGggZW5kcyBvZiB0aGUgU0EgYmVpbmcgY29uZmlndXJl ZCBmb3IgTEIsIHRoZW4gd2UgY2FuIHNpbXBseSB1c2UgdGhlIGV4aXN0aW5nIDQ1MDAgcG9ydCB0 byBkZXNpZ25hdGUgdGhlIEVTUGluVURQIGVuY2Fwc3VsYXRpb24uIFVzaW5nIHRoaXMgb2JzZXJ2 YXRpb24gSVBTRUMgTEIgcGFja2V0cyB0cmFuc21pdHRlZCBmcm9tIHRoZSBpbml0aWF0b3IgKGJl aGluZCB0aGUgTkFQVCkgd291bGQgaGF2ZSBlbnRyb3B5IGluIHRoZSBzb3VyY2UgcG9ydCBhbmQg NDUwMCBpbiB0aGUgZGVzdGluYXRpb24gcG9ydC4NCg0KRWFjaCBJUFNFQyBpbml0aWF0b3IgTEIg cGFja2V0IHdpdGggYSBkaWZmZXJlbnQgZW50cm9weSB2YWx1ZSB3aWxsIHJlc3VsdCBpbiBhIG5l dyBtYXBwaW5nIGF0IHRoZSBOQVBULg0KDQpUaGUgbm9ybWFsIGJlaGF2aW91ciBvZiB0aGUgcmVz cG9uZGVyIChvdXRzaWRlIHRoZSBOQVBUKSBpcyB0byB0cmFuc21pdCB0byB0aGUgZGVzdGluYXRp b24gYWRkcmVzcyBhbmQgcG9ydCBvZiB0aGUgbGFzdCBwYWNrZXQgc291cmNlIGFkZHJlc3MgYW5k IHBvcnQgKGZyb20gdGhlIGluaXRpYXRvciksIGhvd2V2ZXIgdGhpcyBpcyB3aGVyZSB3ZSBkZXZp YXRlIGZvciBhIExCIGltcGxlbWVudGF0aW9uLiBJbnN0ZWFkIHRoZSByZXNwb25kZXIgKG91dHNp ZGUgdGhlIE5BUFQpIHRyYW5zbWl0cyBhbGwgcmVzcG9uc2VzIHRvIHRoZSBhZGRyZXNzIGFuZCBw b3J0IGVzdGFibGlzaGVkIGZvciBJS0UsIGhvd2V2ZXIgd2l0aCBhbiBlbnRyb3B5IHZhbHVlIGlu IHRoZSBzb3VyY2UgcG9ydC4gU2luY2UgdGhlIE5BUFQgaGFzIHRoZSBJS0UgbWFwcGluZyB0aGlz IHdpbGwgZGVsaXZlciB0aGUgRVNQaW5VRFAgcGFja2V0IHRvIHRoZSBpbml0aWF0b3Igd2hlcmUg dGhlIGRlc3RpbmF0aW9uIHBvcnQgd2lsbCBiZSByZXN0b3JlZCB0byA0NTAwIGFuZCB0aGUgc291 cmNlIHBvcnQgd2lsbCBiZSB0aGUgZW50cm9weSB2YWx1ZS4NCg0KU28gdG8geW91ciBxdWVzdGlv biBhYm91dCBOQVBUIGZpbHRlcmluZy4gSWYgdGhlIE5BUFQgZm9sbG93cyBSRVEtOCBpbiBSRkMg NDc4NywgdGhlbiBmaWx0ZXJpbmcgd2lsbCBwYXNzIHRoZSByZXNwb25kZXIgcGFja2V0cyBzaW5j ZSB0aGUgZGVzdGluYXRpb24gYWRkcmVzcyBhbmQgcG9ydCB3aWxsIGJlIG1hcHBlZCBhbmQgdGhl IHNvdXJjZSBhZGRyZXNzIHdpbGwgYWxzbyBiZSBrbm93bi4gSW4gdGhlIGV2ZW50IGEgTkFQVCB2 aW9sYXRlcyBSRVEtOCBhbmQgZG9lcyBBZGRyZXNzIGFuZCBQb3J0IC0gRGVwZW5kZW50IEZpbHRl cmluZyB0aGVuIHRoZSByZXNwb25kZXIgcGFja2V0cyBtaWdodCBiZSBmaWx0ZXJlZC4gVGhlcmUg bWF5IGJlIHNvbHV0aW9ucyBmb3IgdGhpcyBjYXNlLCBob3dldmVyIGZvciB0aGUgcHJlc2VudCBk aXNjdXNzaW9uIGl0IGRvZXMgbm90IHNlZW0gd29ydGggcHVyc3VpbmcgdGhlIGNhc2Ugd2VyZSBh IE5BUFQgdmlvbGF0ZXMgUkVRLTguDQoNCkNoZWVycywNCg0KUGF1bA0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogVG9iaWFzIEJydW5uZXIgW21haWx0bzp0b2JpYXNAc3Ryb25n c3dhbi5vcmddIA0KU2VudDogVGh1cnNkYXksIEp1bHkgMTUsIDIwMjEgMTE6NTIgUE0NClRvOiBC b3R0b3JmZiwgUGF1bCA8cGF1bC5ib3R0b3JmZkBocGUuY29tPjsgVmFsZXJ5IFNteXNsb3YgPHNt eXNsb3YuaWV0ZkBnbWFpbC5jb20+OyAnVGVybyBLaXZpbmVuJyA8a2l2aW5lbkBpa2kuZmk+OyBh bnRvbnkuYW50b255QHNlY3VuZXQuY29tOyAnSVBzZWMnIDxpcHNlY0BpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbSVBzZWNdIGRyYWZ0LXh1LWlwc2VjbWUtZXNwLWluLXVkcC1sYi0wNw0KDQpIaSBQ YXVsLA0KDQo+IFRoZSBwb3J0cyB1c2VkIGZvciBJS0UgcGFja2V0cyB3b3VsZCBub3QgYmUgcmFu ZG9taXplZCBzaW5jZSBJS0Ugd291bGQgbm90IHVzZSBzb3VyY2UgcG9ydCBmb3IgTEIgYW5kIHNv IHNob3VsZCBiZSBzdGFibGUgYXQgdGhlIE5BVC4NCg0KSSB3YXMgbm90IHJlZmVycmluZyB0byB0 aGUgSUtFIGJ1dCB0aGUgRVNQIHBhY2tldHMgc2VudCBieSB0aGUgcmVzcG9uZGVyIHRvIHRoZSBu YXR0ZWQgSUtFIHBvcnQgZm9yIExCLiAgV2Fzbid0IHRoYXQgd2hhdCB5b3Ugd2VyZSBwcm9wb3Np bmc/DQoNClJlZ2FyZHMsDQpUb2JpYXMNCg== From nobody Fri Jul 16 12:46: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 D64F73A4242 for ; Fri, 16 Jul 2021 12:46: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 2TdmtpNLKd9l for ; Fri, 16 Jul 2021 12:46:10 -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 2C6823A4241 for ; Fri, 16 Jul 2021 12:46:10 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4GRMDb5bxkz50w; Fri, 16 Jul 2021 21:46:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1626464767; bh=/DlpdW10YcTIdZ1cw8RhK7iuNmktJL35E9f/OzuKPhc=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=sA/hQLeScHPMNkCynKlNCc/P5A8+ahmhSqeqD0K6TaJMeYfKVzMxg2xhgz2SjbYGG L3oZTsfCWyR9XNp6LGjj4do8zXRkNmZBBTbcjO1afj1gQnAE4G0LhD7tcehx+wZ86Y q3Sbs9WRj3FTAnribF50ywQAY9fjQaLi5DwSgPrs= 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 JRuPSmFM3wR9; Fri, 16 Jul 2021 21:46:06 +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; Fri, 16 Jul 2021 21:46:06 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 6554ACA25D; Fri, 16 Jul 2021 15:46:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 62186CA25C; Fri, 16 Jul 2021 15:46:05 -0400 (EDT) Date: Fri, 16 Jul 2021 15:46:05 -0400 (EDT) From: Paul Wouters To: "Bottorff, Paul" cc: Tobias Brunner , Valery Smyslov , 'Tero Kivinen' , "antony.antony@secunet.com" , 'IPsec' , Mahendra Maddur Puttaswamy , Shraddha Hegde , =?ISO-2022-JP?Q?=1B$B=3Dy=3E=2E8W=1B=28J?= In-Reply-To: Message-ID: <5766259-f771-b4fd-8236-15dfd3c4fb25@nohats.ca> References: <20210331103220.GA21137@moon.secunet.de> <24678.19440.553333.890224@fireball.acr.fi> <036401d72786$91047b90$b30d72b0$@gmail.com> <7cd40215-563d-9860-62fa-4110f1bd3895@strongswan.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07 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, 16 Jul 2021 19:46:15 -0000 On Fri, 16 Jul 2021, Bottorff, Paul wrote: > Somehow I think we are mis-understanding. Please excuse the long introduction to answer your question. I am also very confused. > Consider an IPSEC initiator sitting behind a NAPT talking with an IPSEC responder on the Internet (within a DC). > > The initiator will start with IKE. The IKE packets will not be LB and since a NAPT would be detected, the IKE packets would use source and destination port 4500. Just to clarify, on the initiator those source/dest ports will be 4500, but on the responder the source port can be anything and the destination port will be 4500. > After IKE established the SA, load balancing will be used with ESPinUDP packet exchanges. > > Both the initiator and the responder can exchange ESPinUDP with LB after the SA is established. Which SA? The initial IPsec SA ? > For ESPinUDP with LB the source port will be used for entropy. This does not necessary mean the source port is random, however does mean the source port must cover a range of values sufficient to provide the required level of entropy. Draft-xu-ipsecme-esp-in-udp-lb does not provide specific guidance on entropy values, however for NAT interoperability it is desirable to limit the number of entropy values. I think you are saying "pick a random port and keep using it" and not "use a random port for each packet", right ? > At an IPSEC initiator (behind NAPT) using draft-xu-ipsecme-esp-in-udp-lb will generate LB ESPinUDP packets with the entropy value in the source port and a new destination port Where does this "new destination port" come from? You only have a NAT mapping for port 500 and a NAT mapping for port 4500. Did a new destination port get negotiated over IKE? I don't see that specified in the draft. Or do you expect the non-NAT IPsec endpoint to auto-detect these packets to random ports based on encap payload and SPI ? > , however the use of a new port to designate LB complicates the situation. Instead, if we consider both ends of the SA being configured for LB, then we can simply use the existing 4500 port to designate the ESPinUDP encapsulation. Using this observation IPSEC LB packets transmitted from the initiator (behind the NAPT) would have entropy in the source port and 4500 in the destination port. But when using only destination port 4500, then you run into the problem of NAT mapping updates. If you send a ESPinUDP packet to port 4500 from source port X, the peer will update its IPsec SA endpoint and start sending all packets to that single source port. So any entropy gain is lost. > Each IPSEC initiator LB packet with a different entropy value will result in a new mapping at the NAPT. Yes, a new mapping, but the old mapping will be deleted. Is your draft saying we should _keep_ those mappings? If so, how would you ever detect a _rela_ IKE/ESP port remapping from the NAPT router between the endpoints? > The normal behaviour of the responder (outside the NAPT) is to transmit to the destination address and port of the last packet source address and port (from the initiator) Not without MOBIKE. And with MOBIKE this requires explicit signaling via the INFORMATIONAL IKE message containing an UPDATE_ADDRESS payload. > however this is where we deviate for a LB implementation. Instead the responder (outside the NAPT) transmits all responses to the address and port established for IKE, however with an entropy value in the source port. Since the NAPT has the IKE mapping this will deliver the ESPinUDP packet to the initiator where the destination port will be restored to 4500 and the source port will be the entropy value. I don't see how this can properly work. It would be really helpful if you can explain this with ASCII art in your draft document. > So to your question about NAPT filtering. If the NAPT follows REQ-8 in RFC 4787, then filtering will pass the responder packets since the destination address and port will be mapped and the source address will also be known. In the event a NAPT violates REQ-8 and does Address and Port - Dependent Filtering then the responder packets might be filtered. There may be solutions for this case, however for the present discussion it does not seem worth pursuing the case were a NAPT violates REQ-8. I still don't see how you avoid reducing everything to 1 NAT mapping on the NAPT router, and thus with no extra entropy, as it seems multiple different source IPs are racing with the regular endpoint NAT mapping update. And if you change that behaviour to not update but keep the old NAT mappings, you need to not only change the kernel behaviour, you also need to signal whether this is supported through IKE, and whether you want it activated. Eg you would need some _SUPPORTED notify and then some USE_ notify. Paul W From nobody Fri Jul 16 13:50: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 09DDC3A0896 for ; Fri, 16 Jul 2021 13:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hpe.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 ukecYXBaSyq0 for ; Fri, 16 Jul 2021 13:50:37 -0700 (PDT) Received: from mx0b-002e3701.pphosted.com (mx0b-002e3701.pphosted.com [148.163.143.35]) (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 A93D03A0890 for ; Fri, 16 Jul 2021 13:50:32 -0700 (PDT) Received: from pps.filterd (m0134425.ppops.net [127.0.0.1]) by mx0b-002e3701.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 16GKgtcN029950; Fri, 16 Jul 2021 20:50:27 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hpe.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=pps0720; bh=0otSsUOREY/Bb7LMwca/jHF9/ve3cXCo/NTaPybrFJg=; b=GqEIVFiqODCY1mBDJebFZkodJAO3/5LlSlstvTHKODG/ov5KZXh1U1m2jxPm0askh+SH Yg5TXJd7aG4pG9Pz6bXTLcfHqrzJULX22/8pkZJKKMDnYWZAuRrJxZE02qvJ5cr4L4uZ QoIPcURYaESb1Azy+ezoXEpOG9NKEKf3ZFUfwzP01UvGKp/uc1JYcBs9zIseeq+9d6Bq nM91x5K7QhhRguMHQRPIwnuqKsmy1tv6uK1VYxIFjU7W8D4lzxN6Z9Xfv2+U1C49Ijpr wvtZdzlL/QJpF8r2dJJq+WL0eE2gpMmAv9rQr99IWneTlcZHRnPcOEr61r23EkULhp+G Qg== Received: from g9t5008.houston.hpe.com (g9t5008.houston.hpe.com [15.241.48.72]) by mx0b-002e3701.pphosted.com with ESMTP id 39twy4h17f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 16 Jul 2021 20:50:26 +0000 Received: from G4W9119.americas.hpqcorp.net (exchangepmrr1.us.hpecorp.net [16.210.20.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by g9t5008.houston.hpe.com (Postfix) with ESMTPS id 8EA1C4F; Fri, 16 Jul 2021 20:50:25 +0000 (UTC) Received: from G9W8453.americas.hpqcorp.net (2002:10d8:a0d3::10d8:a0d3) by G4W9119.americas.hpqcorp.net (2002:10d2:14d6::10d2:14d6) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Fri, 16 Jul 2021 20:50:25 +0000 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (15.241.52.11) by G9W8453.americas.hpqcorp.net (16.216.160.211) with Microsoft SMTP Server (TLS) id 15.0.1497.18 via Frontend Transport; Fri, 16 Jul 2021 20:50:25 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=L4uzuxM8iO5/rHNLq89UNNRBF7FGjUAeNz+Bz7kNOXRpq8pGVFUBUnxy8HMhnY2i5bc+kAAoHiC3Eqva3Fx2girQAS5qA4XHbOL6seVJPj73UiTOCMfeA3T0HWAH1co8ZdzLqIY+7OlRT4i3dgQA5CbsUdY9lHVeRy8235lpen24aGYBFob84BLYtvAChMXWsZowHVd6h60qnPYM6qb0u7uqxNNE3CtEPcNivWWA9baOZh/adsLmAWIK/D8sx14/i6W4V4/xWcNCvW7ElO8wqTsjAd2HHawlYShErbqkIlAfjQgx9LPaExM0d1gKKuE93AKsQs3x6oxv86FarIdUAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0otSsUOREY/Bb7LMwca/jHF9/ve3cXCo/NTaPybrFJg=; b=ZFNma8Y216Ie+SwgrBNmuzuS8rC7SBIoiIGabTCew2oJ7vc/G+ZsJ1j2V3XkQ6uA3O0FtTMXvc3FzNY/XCXYQZnMcHgEwhVb6aPU5M/IFUoeCq2xRxQzddzjo6bH3pAf+B4mxG39rl6ibA8JZL7oMer3B5Wem3fgFEffq+djnk/KuEajFaFSJw7slY4dOfwBX7tsTFvl4Av34GOOg94tDcBbzhJOVZtVe1pKyk12MffPG8R+r/CLqzsNaKk12kmF/nxzb1ljbsrwiuXN7r0DsP1uMvLI16+J2GEnci+1d/A4SwSGPHZTsvZGE0ssONaT0pHt9PtlxeuPRv+kKkaeSw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=hpe.com; dmarc=pass action=none header.from=hpe.com; dkim=pass header.d=hpe.com; arc=none Received: from CS1PR8401MB1192.NAMPRD84.PROD.OUTLOOK.COM (2a01:111:e400:7507::23) by CS1PR8401MB0408.NAMPRD84.PROD.OUTLOOK.COM (2a01:111:e400:7512::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.23; Fri, 16 Jul 2021 20:50:23 +0000 Received: from CS1PR8401MB1192.NAMPRD84.PROD.OUTLOOK.COM ([fe80::a4ff:aeb9:d100:6536]) by CS1PR8401MB1192.NAMPRD84.PROD.OUTLOOK.COM ([fe80::a4ff:aeb9:d100:6536%9]) with mapi id 15.20.4331.026; Fri, 16 Jul 2021 20:50:23 +0000 From: "Bottorff, Paul" To: Paul Wouters CC: Tobias Brunner , Valery Smyslov , 'Tero Kivinen' , "antony.antony@secunet.com" , 'IPsec' , Mahendra Maddur Puttaswamy , Shraddha Hegde , =?iso-2022-jp?B?GyRCPXk+LjhXGyhC?= Thread-Topic: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07 Thread-Index: AdciaiROLLoGnn3oQyW5+9ys0PMxKgJRErFpANOS/JYCNRDTH6tGNXFQq2XEr5DWKZkDwNOtc7uA//9oygCAAgxigP//WMdwAC/0AID///ktYA== Date: Fri, 16 Jul 2021 20:50:23 +0000 Message-ID: References: <20210331103220.GA21137@moon.secunet.de> <24678.19440.553333.890224@fireball.acr.fi> <036401d72786$91047b90$b30d72b0$@gmail.com> <7cd40215-563d-9860-62fa-4110f1bd3895@strongswan.org> <5766259-f771-b4fd-8236-15dfd3c4fb25@nohats.ca> In-Reply-To: <5766259-f771-b4fd-8236-15dfd3c4fb25@nohats.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nohats.ca; dkim=none (message not signed) header.d=none;nohats.ca; dmarc=none action=none header.from=hpe.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9758f909-ca58-4f54-a630-08d9489b551b x-ms-traffictypediagnostic: CS1PR8401MB0408: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WBkhpoQaiERBOXIDe+ttket5e3lsC2+5/l9pIm9vblsSlv8EgGEGBHbWJ5YsxxLVDcaScNhfo9eSDMPsmp4nvVi0lGe+djwmaVrHoHt3ROViqqFQYqUmMKrz0b2vBjaGlMCgDQa7aNcNJgodb1ZM1XAKTOVHi8Q4ZWobL7k3K9q9z7XSwVLj87kWUVuVHf6F/Tq5S6vVGuTOoyzi8Ow2S94fBaQ6T7coTNEU4ZzSN/rcqb/Bt5HIudNLsQt9G3y9DUHaGnJlRUSXtphiSuy1MQTyB0il1D5pqwm6o/e+2GBImLSblDXtLoVf/7+ner9u8u7sA7GjFzEVfgvu06YpzJoAins4TvETHublB6SIQyttm+c98B0gUzkIT2fIOMpsHpQ3Ztwl+SOtLXUJ+CGw8DbrPe3Jq8PvkXC+H7IxzJlKuqPEnoSy9ZH84fdjdDlTpfaGLp/CXAwgl8loqgrdHpQtU6OKSOgoaOnDCZhCKxYDC7moQcC295WcQcRJ2fwf8cRU8OXa3zHJJ26sx07QMuycoKMJq1LevChXz9jeUjdEN8wUGj2lc32CvbgP44mqa7w2PwN86qokj4vIkJa99CNF3X9KfBHKIKZLhHey+vQtD7QQ7JHhmQwUnmF7m9r7SogKSDbKbQtF2VJKCQsy6iZ8zyzBXrQtofkIE5U4Av1NlRv+tjagy1yManoz1RfGbRmAdDLh+jTEvZ27H0mZOA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CS1PR8401MB1192.NAMPRD84.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(64756008)(66446008)(66556008)(66946007)(76116006)(7696005)(6916009)(66476007)(2906002)(86362001)(9686003)(53546011)(508600001)(71200400001)(186003)(26005)(55016002)(122000001)(38100700002)(55236004)(6506007)(5660300002)(52536014)(66574015)(316002)(83380400001)(33656002)(54906003)(4326008)(8676002)(8936002)(38070700004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-2022-jp?B?RlJoK0NoajFHYmpKRThiY3hvdkM4N00yOFplT0VzcUVvVlBKZlRhd1Bm?= =?iso-2022-jp?B?V3NPVFNhamFmM0hrQXk2cVB0bVhYeGEwZFpKaGx4S3Q5elREbWpEZnND?= =?iso-2022-jp?B?RmQ3d3FMUFlWaWg5ZVZvQU5NLzZiZytVaTR6MTg1RUlHT3FTcUhzNE52?= =?iso-2022-jp?B?TGxPbVl6YjN5WGttN2NQZDR2N2pZd045R2xDZjB6VzA2VCs3a3dicmxO?= =?iso-2022-jp?B?Qkx6N2ZIL21NYjRUeCt0S2xEZUovcW1aS3I4SEt1cU5yMHc1cDFWeVZK?= =?iso-2022-jp?B?UkE5dU9tTU5KNVpjYldIbC8vYVVsNzM2LzZhaUNOL0RoSkR1Wk02Vmdq?= =?iso-2022-jp?B?enpZNjFCWi9VQ0ZITlczV296ZDYrc3B6TTRBd2lQamVJZ0czUTRvRm1x?= =?iso-2022-jp?B?WGI3bmk2c2IxeU1KMXhkb3pxOWpxNDVxN2s4emhXZG5kNVBYQnVGcXQ3?= =?iso-2022-jp?B?SDNyTEEzMVloTDF4VSttV1h4L01ZTnFTSEJtdWRzeDVlOEFYa29KNzNP?= =?iso-2022-jp?B?SzhoS1ZHcGVNa3gvb2NWZXhjakpVU1MvckFPaEdjWnE1OFdmVmVPSFd0?= =?iso-2022-jp?B?b0Rma05QK1lxRmhXbnlrcUUxL1dkWnY0bUFjanIrMi9ycDJhR3hrMmVL?= =?iso-2022-jp?B?LzlMZ2RmRTNSZEFMK2RENzZnalNNUE91dzQ2Qk9oZ3Z6bFRwSnFsS2hF?= =?iso-2022-jp?B?a2N1dUNtemM4UXJGV1VyWGc3cVlHdGdsdzJnM2dEWFR3OHhLVUFIS1kz?= =?iso-2022-jp?B?K2hPbmNCQUZoRGQvbGVlY1E0MHFDV08ySndrdy9lRGRQaDY5eHlYbEM3?= =?iso-2022-jp?B?WUJKZXlxY1pWWitpVGlWdzhvTmRyNjRsNHJsVkhBbU9OdTN1R09FaG4r?= =?iso-2022-jp?B?YWoxQTlBeEVrMWlaMlBKK084M1RIdVhLZkZ6SENsNEJYVENDRHg4bTRN?= =?iso-2022-jp?B?VDhtdkJId1ppcWdqN2tiNmVyeFl3MEs2MGxabHVOUW9PSWx3TTc0eG5x?= =?iso-2022-jp?B?VXBHZXNwVzRha2VPR0ZhdDEwaitkVEZndXRKUnUzMko4Y0NUMHREYSs2?= =?iso-2022-jp?B?R2RjcWZkbmVEd1dnY0dLYnFwNGYrMWpwQmQreUxFeE9zT1pHRUUwM2du?= =?iso-2022-jp?B?Rk13MFJKUWZmbUNBbjFWeGVjc3NWWTB4citZY1VTRE4rampnbUFwSFJs?= =?iso-2022-jp?B?eXpuajYwaFAzb1h6T0ZHQW5mVnd3THBFNmxwTEdCcHJjRGttaTJTZ1Bn?= =?iso-2022-jp?B?K1VHdmxveUZiQnFqWjZtWncxSjd2ZTRsa3hRUG00N3JLWnRWUDd1ZzV4?= =?iso-2022-jp?B?cE5mb21KcE52dUw0S0tiVDhaRkkwaUh6R0JXNERkV2VtRkJraE05bnc4?= =?iso-2022-jp?B?MWM1YWhQOGdSbzhUaDhoYW9EUDlyRWw0UG9WKy9yWFNZOUFsRzVlRngw?= =?iso-2022-jp?B?UVhmM1RkREhoa0Y3YVF3a3ZNekJCbTdkMG1uNGp1Q3VrZEdmK1h2U0Z6?= =?iso-2022-jp?B?MytxZzdtb0FXbWJ6cWVxMENJbmkrRThHLzBvZ3RuNWMrSVZ2WldUOWxh?= =?iso-2022-jp?B?U3pNcTN6WVRocGRKRXVQWFdPejI0RFl4Wml0MmFjSU55L2lTUUdHMVAx?= =?iso-2022-jp?B?TnJEZXlwMG9rZHg0eDZvRS8rQW5NcGd1bVRJN3NKWGtyV3JaaWNybTFx?= =?iso-2022-jp?B?UXVDckRiaTU3bkhPbmx1Yzk2NnRJc0k1bDR2ZWZXbzZrdWlDY0lyVE9l?= =?iso-2022-jp?B?T1VneUd6eHZuaUQ3R3RRTk1ScUYyZ01Vdm5GQjFGMnJaUi9CT1hVTEMr?= =?iso-2022-jp?B?WG1Ta1RQK1NKZ2pVRGl0WjlQK2tEZWpXKytqeU85bHNxcGkwdU8rSThq?= =?iso-2022-jp?B?TGpKTm4zMnMwdVVDcEtJZW9MV0JzSFYvV2k3ZVU2RVRteCtTYi94UFhs?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-2022-jp" X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CS1PR8401MB1192.NAMPRD84.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 9758f909-ca58-4f54-a630-08d9489b551b X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2021 20:50:23.3342 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: k15n/tlcTmCYEWv3V1eShgfc5/X+Il4NAetyiJsQ/wcvCpn50omrA4vRDAM355QgJzeBZwbvu1q5rB7tvw7Cwg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CS1PR8401MB0408 X-OriginatorOrg: hpe.com X-Proofpoint-GUID: 9zwXELhV1eStpApx1Bp62QWwTvkw-lgX X-Proofpoint-ORIG-GUID: 9zwXELhV1eStpApx1Bp62QWwTvkw-lgX Content-Transfer-Encoding: quoted-printable X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-HPE-SCL: -1 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-16_09:2021-07-16, 2021-07-16 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 bulkscore=0 priorityscore=1501 spamscore=0 phishscore=0 malwarescore=0 mlxlogscore=999 lowpriorityscore=0 suspectscore=0 clxscore=1011 adultscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107160131 Archived-At: Subject: Re: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07 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, 16 Jul 2021 20:50:44 -0000 Hi Paul: Below, Cheers, Paul -----Original Message----- From: Paul Wouters [mailto:paul@nohats.ca]=20 Sent: Friday, July 16, 2021 12:46 PM To: Bottorff, Paul Cc: Tobias Brunner ; Valery Smyslov ; 'Tero Kivinen' ; antony.antony@secunet.com; 'IPse= c' ; Mahendra Maddur Puttaswamy ; S= hraddha Hegde ; =1B$B=3Dy>.8W=1B(B Subject: Re: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07 On Fri, 16 Jul 2021, Bottorff, Paul wrote: > Somehow I think we are mis-understanding. Please excuse the long introduc= tion to answer your question. I am also very confused. > Consider an IPSEC initiator sitting behind a NAPT talking with an IPSEC r= esponder on the Internet (within a DC). > > The initiator will start with IKE. The IKE packets will not be LB and sin= ce a NAPT would be detected, the IKE packets would use source and destinati= on port 4500. Just to clarify, on the initiator those source/dest ports will be 4500, but= on the responder the source port can be anything and the destination port = will be 4500. PB>No, on the responder the destination port is not 4500, but is the source= port received from the initiator. The reason for this is the NAPT translat= ed the source port of the initiator IKE packet and to reverse the mapping a= s the responder sends to the initiator it must use the port mapped by the N= APT as the destination. This port will be translated back to 4500 by the NA= PT before it is delivered to the initiator behind the NAPT. > After IKE established the SA, load balancing will be used with ESPinUDP p= acket exchanges. > > Both the initiator and the responder can exchange ESPinUDP with LB after = the SA is established. Which SA? The initial IPsec SA ? > For ESPinUDP with LB the source port will be used for entropy. This does = not necessary mean the source port is random, however does mean the source = port must cover a range of values sufficient to provide the required level = of entropy. Draft-xu-ipsecme-esp-in-udp-lb does not provide specific guidan= ce on entropy values, however for NAT interoperability it is desirable to l= imit the number of entropy values. I think you are saying "pick a random port and keep using it" and not "use = a random port for each packet", right ? PB>More precisely, pick a range of ports for use as entropy code points and= use them by mapping the flows of the packets within the ESP to them. The s= ource port picked is not really random since for LB to work properly we mus= t retain flow integrity. Typically the port would be determined by a hash o= f the packet now encrypted with as an ESP. Also we can't choose a single po= rt for entropy since the objective is to use the source port for spreading = traffic over multiple paths. What I am saying is that for most applications= we can choose (preferably contiguous) a port range (which might be as smal= l as 2 ports or as large as 256 ports) which would be used for LB. The choi= se of these ports would then depend on the hash function applied to inside = packet before ESP. > At an IPSEC initiator (behind NAPT) using=20 > draft-xu-ipsecme-esp-in-udp-lb will generate LB ESPinUDP packets with=20 > the entropy value in the source port and a new destination port Where does this "new destination port" come from? You only have a NAT mappi= ng for port 500 and a NAT mapping for port 4500. Did a new destination port= get negotiated over IKE? I don't see that specified in the draft. Or do yo= u expect the non-NAT IPsec endpoint to auto-detect these packets to random = ports based on encap payload and SPI ? PB>The new source port is proposed by draft-xu-ipsecme-esp-in-udp-lb and is= to be obtained from IANA. This is a point of disagreement between myself a= nd the authors of draft-xu-ipsecme-esp-in-udp-lb which I describe in a litt= le more detail as follows. > , however the use of a new port to designate LB complicates the situation= . Instead, if we consider both ends of the SA being configured for LB, then= we can simply use the existing 4500 port to designate the ESPinUDP encapsu= lation. Using this observation IPSEC LB packets transmitted from the initia= tor (behind the NAPT) would have entropy in the source port and 4500 in the= destination port. But when using only destination port 4500, then you run into the problem of= NAT mapping updates. If you send a ESPinUDP packet to port 4500 from sourc= e port X, the peer will update its IPsec SA endpoint and start sending all = packets to that single source port. So any entropy gain is lost. PB>We are in agreement here. What I am proposing is that this IPSEC behavio= ur (dynamic updating) needs to change to support LB through NAT. To support= IPSEC LB through NAPT. For LB the IPsec SA endpoint needs to NOT update it= s end point, but instead use the end point established for IKE. > Each IPSEC initiator LB packet with a different entropy value will result= in a new mapping at the NAPT. Yes, a new mapping, but the old mapping will be deleted. Is your draft sayi= ng we should _keep_ those mappings? If so, how would you ever detect a _rel= a_ IKE/ESP port remapping from the NAPT router between the endpoints? PB>The mappings generated by ESPinUDP with LB don't need to be preserved, o= nly the IKE mapping needs to be preserved. Since IKE used a different sourc= e port (4500) from the ESPinUDP LB packets these should appear at different= non-overlapping translations. > The normal behaviour of the responder (outside the NAPT) is to=20 > transmit to the destination address and port of the last packet source=20 > address and port (from the initiator) Not without MOBIKE. And with MOBIKE this requires explicit signaling via th= e INFORMATIONAL IKE message containing an UPDATE_ADDRESS payload. PB>I not certain we disagree since this is a matter of frame of reference. = The initiator will always see the same destination port and addresses. > however this is where we deviate for a LB implementation. Instead the res= ponder (outside the NAPT) transmits all responses to the address and port e= stablished for IKE, however with an entropy value in the source port. Since= the NAPT has the IKE mapping this will deliver the ESPinUDP packet to the = initiator where the destination port will be restored to 4500 and the sourc= e port will be the entropy value. I don't see how this can properly work. It would be really helpful if you c= an explain this with ASCII art in your draft document. PB>I have not put forward any draft on this topic, because my use case does= not have any need for NAT. See draft-bottorff-ipsecme-mtdcuc-psec-lb. The = only reason I bring it up is that NAT was raised as an issue in the previou= s email thread on draft-xu-ipsecme-esp-in-udp-lb. My only intent is to sugg= est that there probably is a way to solve NAPT traversal combined with LB. > So to your question about NAPT filtering. If the NAPT follows REQ-8 in RF= C 4787, then filtering will pass the responder packets since the destinatio= n address and port will be mapped and the source address will also be known= . In the event a NAPT violates REQ-8 and does Address and Port - Dependent = Filtering then the responder packets might be filtered. There may be soluti= ons for this case, however for the present discussion it does not seem wort= h pursuing the case were a NAPT violates REQ-8. I still don't see how you avoid reducing everything to 1 NAT mapping on the= NAPT router, and thus with no extra entropy, as it seems multiple differen= t source IPs are racing with the regular endpoint NAT mapping update. And i= f you change that behaviour to not update but keep the old NAT mappings, yo= u need to not only change the kernel behaviour, you also need to signal whe= ther this is supported through IKE, and whether you want it activated. Eg y= ou would need some _SUPPORTED notify and then some USE_ notify. Paul W From nobody Thu Jul 22 11:43: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 AFF573A0D75 for ; Thu, 22 Jul 2021 11:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.304 X-Spam-Level: X-Spam-Status: No, score=-1.304 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, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 yPbvbe62izLo for ; Thu, 22 Jul 2021 11:43:09 -0700 (PDT) Received: from mx.nohats.ca (unknown [193.110.157.85]) (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 1E4EB3A0D4D for ; Thu, 22 Jul 2021 11:43:03 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4GW1Y11k4Jz319; Thu, 22 Jul 2021 20:43:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1626979381; bh=Q5MBps22eRcS5UtgN3eQTeaf3zQ+pHsQZBZ66PKOiyU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=YYvMOYgJmdL7K1cCfM86BhBOhpfBRq/sz1SqXExsDAnWrbYJkrevYUatuWwf0fl2X Is1v9rzuKiyL817+uwhox6NntygxfghuYo7zLsieRgQXcYyrCujVZYgROhlCEiZVPW X+BitIjspvCuJiZze1rqCbEwth8eAghvp2My15V4= 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 Wo1cweJNfFus; Thu, 22 Jul 2021 20:42:59 +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; Thu, 22 Jul 2021 20:42:59 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id B87D2CE57A; Thu, 22 Jul 2021 14:42:57 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B5408CE579; Thu, 22 Jul 2021 14:42:57 -0400 (EDT) Date: Thu, 22 Jul 2021 14:42:57 -0400 (EDT) From: Paul Wouters To: "Bottorff, Paul" cc: Tobias Brunner , Valery Smyslov , 'Tero Kivinen' , "antony.antony@secunet.com" , 'IPsec' , Mahendra Maddur Puttaswamy , Shraddha Hegde , =?ISO-2022-JP?Q?=1B$B=3Dy=3E=2E8W=1B=28J?= In-Reply-To: Message-ID: <1cd199e7-2db4-7547-59d4-9cdf0aa1671@nohats.ca> References: <20210331103220.GA21137@moon.secunet.de> <24678.19440.553333.890224@fireball.acr.fi> <036401d72786$91047b90$b30d72b0$@gmail.com> <7cd40215-563d-9860-62fa-4110f1bd3895@strongswan.org> <5766259-f771-b4fd-8236-15dfd3c4fb25@nohats.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp; format=flowed Archived-At: Subject: Re: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07 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, 22 Jul 2021 18:43:16 -0000 On Fri, 16 Jul 2021, Bottorff, Paul wrote: > Hi Paul: > > Below, > > Cheers, The below did not clear things up for me. I think it would be useful to describe things in the draft much more carefully and details with some ascii art. Paul > Paul > > -----Original Message----- > From: Paul Wouters [mailto:paul@nohats.ca] > Sent: Friday, July 16, 2021 12:46 PM > To: Bottorff, Paul > Cc: Tobias Brunner ; Valery Smyslov ; 'Tero Kivinen' ; antony.antony@secunet.com; 'IPsec' ; Mahendra Maddur Puttaswamy ; Shraddha Hegde ; $B=y>.8W(J > Subject: Re: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07 > > On Fri, 16 Jul 2021, Bottorff, Paul wrote: > >> Somehow I think we are mis-understanding. Please excuse the long introduction to answer your question. > > I am also very confused. > >> Consider an IPSEC initiator sitting behind a NAPT talking with an IPSEC responder on the Internet (within a DC). >> >> The initiator will start with IKE. The IKE packets will not be LB and since a NAPT would be detected, the IKE packets would use source and destination port 4500. > > Just to clarify, on the initiator those source/dest ports will be 4500, but on the responder the source port can be anything and the destination port will be 4500. > > PB>No, on the responder the destination port is not 4500, but is the source port received from the initiator. The reason for this is the NAPT translated the source port of the initiator IKE packet and to reverse the mapping as the responder sends to the initiator it must use the port mapped by the NAPT as the destination. This port will be translated back to 4500 by the NAPT before it is delivered to the initiator behind the NAPT. > >> After IKE established the SA, load balancing will be used with ESPinUDP packet exchanges. >> >> Both the initiator and the responder can exchange ESPinUDP with LB after the SA is established. > > Which SA? The initial IPsec SA ? > >> For ESPinUDP with LB the source port will be used for entropy. This does not necessary mean the source port is random, however does mean the source port must cover a range of values sufficient to provide the required level of entropy. Draft-xu-ipsecme-esp-in-udp-lb does not provide specific guidance on entropy values, however for NAT interoperability it is desirable to limit the number of entropy values. > > I think you are saying "pick a random port and keep using it" and not "use a random port for each packet", right ? > > PB>More precisely, pick a range of ports for use as entropy code points and use them by mapping the flows of the packets within the ESP to them. The source port picked is not really random since for LB to work properly we must retain flow integrity. Typically the port would be determined by a hash of the packet now encrypted with as an ESP. Also we can't choose a single port for entropy since the objective is to use the source port for spreading traffic over multiple paths. What I am saying is that for most applications we can choose (preferably contiguous) a port range (which might be as small as 2 ports or as large as 256 ports) which would be used for LB. The choise of these ports would then depend on the hash function applied to inside packet before ESP. > >> At an IPSEC initiator (behind NAPT) using >> draft-xu-ipsecme-esp-in-udp-lb will generate LB ESPinUDP packets with >> the entropy value in the source port and a new destination port > > Where does this "new destination port" come from? You only have a NAT mapping for port 500 and a NAT mapping for port 4500. Did a new destination port get negotiated over IKE? I don't see that specified in the draft. Or do you expect the non-NAT IPsec endpoint to auto-detect these packets to random ports based on encap payload and SPI ? > > PB>The new source port is proposed by draft-xu-ipsecme-esp-in-udp-lb and is to be obtained from IANA. This is a point of disagreement between myself and the authors of draft-xu-ipsecme-esp-in-udp-lb which I describe in a little more detail as follows. > >> , however the use of a new port to designate LB complicates the situation. Instead, if we consider both ends of the SA being configured for LB, then we can simply use the existing 4500 port to designate the ESPinUDP encapsulation. Using this observation IPSEC LB packets transmitted from the initiator (behind the NAPT) would have entropy in the source port and 4500 in the destination port. > > But when using only destination port 4500, then you run into the problem of NAT mapping updates. If you send a ESPinUDP packet to port 4500 from source port X, the peer will update its IPsec SA endpoint and start sending all packets to that single source port. > So any entropy gain is lost. > > PB>We are in agreement here. What I am proposing is that this IPSEC behaviour (dynamic updating) needs to change to support LB through NAT. To support IPSEC LB through NAPT. For LB the IPsec SA endpoint needs to NOT update its end point, but instead use the end point established for IKE. > >> Each IPSEC initiator LB packet with a different entropy value will result in a new mapping at the NAPT. > > Yes, a new mapping, but the old mapping will be deleted. Is your draft saying we should _keep_ those mappings? If so, how would you ever detect a _rela_ IKE/ESP port remapping from the NAPT router between the endpoints? > > PB>The mappings generated by ESPinUDP with LB don't need to be preserved, only the IKE mapping needs to be preserved. Since IKE used a different source port (4500) from the ESPinUDP LB packets these should appear at different non-overlapping translations. > >> The normal behaviour of the responder (outside the NAPT) is to >> transmit to the destination address and port of the last packet source >> address and port (from the initiator) > > Not without MOBIKE. And with MOBIKE this requires explicit signaling via the INFORMATIONAL IKE message containing an UPDATE_ADDRESS payload. > > PB>I not certain we disagree since this is a matter of frame of reference. The initiator will always see the same destination port and addresses. > >> however this is where we deviate for a LB implementation. Instead the responder (outside the NAPT) transmits all responses to the address and port established for IKE, however with an entropy value in the source port. Since the NAPT has the IKE mapping this will deliver the ESPinUDP packet to the initiator where the destination port will be restored to 4500 and the source port will be the entropy value. > > I don't see how this can properly work. It would be really helpful if you can explain this with ASCII art in your draft document. > > PB>I have not put forward any draft on this topic, because my use case does not have any need for NAT. See draft-bottorff-ipsecme-mtdcuc-psec-lb. The only reason I bring it up is that NAT was raised as an issue in the previous email thread on draft-xu-ipsecme-esp-in-udp-lb. My only intent is to suggest that there probably is a way to solve NAPT traversal combined with LB. > >> So to your question about NAPT filtering. If the NAPT follows REQ-8 in RFC 4787, then filtering will pass the responder packets since the destination address and port will be mapped and the source address will also be known. In the event a NAPT violates REQ-8 and does Address and Port - Dependent Filtering then the responder packets might be filtered. There may be solutions for this case, however for the present discussion it does not seem worth pursuing the case were a NAPT violates REQ-8. > > I still don't see how you avoid reducing everything to 1 NAT mapping on the NAPT router, and thus with no extra entropy, as it seems multiple different source IPs are racing with the regular endpoint NAT mapping update. And if you change that behaviour to not update but keep the old NAT mappings, you need to not only change the kernel behaviour, you also need to signal whether this is supported through IKE, and whether you want it activated. Eg you would need some _SUPPORTED notify and then some USE_ notify. > > Paul W > From nobody Fri Jul 23 09:14: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 D8C9C3A090F for ; Fri, 23 Jul 2021 09:14:04 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcW-ReW-Gp_6 for ; Fri, 23 Jul 2021 09:14:00 -0700 (PDT) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [IPv6:2a0b:5c81:1c1::37]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC7E83A0909 for ; Fri, 23 Jul 2021 09:13:59 -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@iki.fi) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 3B1171B0004B for ; Fri, 23 Jul 2021 19:13:56 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1627056836; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=eDz8BnyI2jno+e7y7+KcKst2emAvv25vZFBHyn1OB70=; b=LSgI9uazKqq2pQyVywetN5+3SxL+YHks5t5bZPz1Fq8d684IUrUJoNctzTVEpegOF/I4zR +fm7cEmcZEgd7dwXaBpHWW6VtljE23dxmgBrP5RfFdVTtaXmCwSITYCNKLDHjZD/R4dUdX OKn8YjSVohlLywt9ozRbFY8wzsk9iz6pUcLSqKvSmV5S+jFf704FdU3TijiCLZrDpBqWIo HMECms8MGPDPn23tq7xuQDrgwDepMPSIhQIrM1ZgUN217DjhMomGI7X4VUkRRJ8UgTv4z2 BHTWDZrlip/Gfl+BPhUR86Z2Pq6LmlBXH1vrTccExUa/JeKRZQx6NrdZUY5lig== Received: by fireball.acr.fi (Postfix, from userid 15204) id E29D825C12AA; Fri, 23 Jul 2021 19:13:54 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24826.60098.876589.209230@fireball.acr.fi> Date: Fri, 23 Jul 2021 19:13:54 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 0 min X-Total-Time: 0 min ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1627056836; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=eDz8BnyI2jno+e7y7+KcKst2emAvv25vZFBHyn1OB70=; b=nqVyhAr6Yw6dFpotIhmOWvBG+3BM7MqhrBcbz0OiS2lgn2TPr8w3/3vJnshjT1Wv21WONm DUtVwp++KsfxPvJaC5Zs8Tq+PXMJtCKPeavpeo800EVm4QkzKX57s+M69pJ1ha50o/bM6/ xpEK0Zh/oeVop34aA3vo+6Lw3uH9WMx6Ezl+ojyRQ0MK0voPBGnTV6VPg2DpIF4QOlfnh3 d5hnx/3PV4KCB7wjESnFABijHxwZLYQATkTrdIwg2/A4gDebb56uMlkboBCrh+w7whcELm rNZikPIZO5eOaqlkfX4GzCDih9rQ+ry9n+DHnUEXInLWfXohJm0Bnrk8p32umg== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1627056836; a=rsa-sha256; cv=none; b=G1mj7a42PvdlUy/Nc6SHAq0ogjbAEMXJDrAtZun6lbAin74STjSpB6u78OnHmSP2adra0r d7hhmAk8kH8bTMH5jMvWiAXnv5ctTaS6yBTLquwrlpx14kP0m+xnJB8CWjpr5KrsMiLTGb tfovnjDojoIoHco0UfYKb4uk1iuuvSFOR3dXDrXf4FbgMmBwDKYLDcWZrlJC9YMp5PqpJX WExW0IVkOIAzV8s5vKGyofGuQ4sKp7BEqMYa1Ci2w1XisH/gEap7D2A5psVMiSOubRFPjD HH2Rpa2eI/hqg7gc8/CnjAzHZFLowe9cyEwZYPjfIz6uT0CR9PMcxV/K4nehuw== Archived-At: Subject: [IPsec] IPsecME Agenda for 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: Fri, 23 Jul 2021 16:14:05 -0000 IP Security Maintenance and Extensions (IPsecME) WG. IETF 111 - Monday July 26th, 2021 21:30-22:30 UTC https://meetings.conf.meetecho.com/ietf111/?group=ipsecme&short=&item=1 Agenda - Note Well, technical difficulties and agenda bashing - Chairs (5 min) - Document Status - Chairs (5 min) - Work items - Hybrid IKEv2 Interoperability Testing Valery Smyslov (5 min) - Improvements for post-quantum IKEv2 Daniel Herzinger (5 min) - Management of IPTFS (Yang and SNMP draft) (draft-ietf-ipsecme-yang-iptfs and draft-ietf-ipsecme-mib-iptfs) Christian Hopps (10 min) - New items - Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Encrypted DNS (draft-btw-add-ipsecme-ike) Valery Smyslov (10 min) - Beyond 64KB Limit of IKEv2 Payloads (draft-tjhai-ikev2-beyond-64k-limit) Valery Smyslov (10 min) - IKEv2 Optional SA&TS Payloads in Child Exchange (draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt) William Panwei (5 min) - IKEv2 support for per-queue Child SAs (draft-pwouters-ipsecme-multi-sa-performance) Paul Wouters (5 min) - AOB + Open Mic (0 min) -- kivinen@iki.fi From nobody Mon Jul 26 09:24: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 BD9073A1C24; Mon, 26 Jul 2021 09:24:06 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZc_kOgf3WaB; Mon, 26 Jul 2021 09:24:01 -0700 (PDT) Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (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 DB22C3A1C23; Mon, 26 Jul 2021 09:24:00 -0700 (PDT) Received: by mail-qv1-xf36.google.com with SMTP id db14so4601400qvb.10; Mon, 26 Jul 2021 09:24:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=m7xRGgUSA8V48ojN94m2x+4s++/jOP5mdIp4AZ/vf5g=; b=LLermiBZ4txPa1b9/3Hmj5/7fhAaPH9nJ27WIwWNNe2QrzaOxRBky3locjcv2QfeJu Q0r7TkZw7HO9VZX7OIhduWAE8tkVlaiGmDI0PYbZxXWgRp5Jfww+x/93jUo01hv+f8JZ aAJt7SwxXNt+pVFlPpefijJajmeXUttZZEKuHdgSrYvvKPgdtNcJ0/CO1/Rf2Vgf2gdb e/yie3BBwzPsIFN9RKese7Wi+YXYlrHod/eUzmJf4xX9bQtqKwsHf2istraASeErlTSn /GB8BCbU89t/2TVA/88eU4Jcmae+15hOrbGc+G/TpjY32otUHW4GmSxNqW+ZwcG0DaUp bEXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=m7xRGgUSA8V48ojN94m2x+4s++/jOP5mdIp4AZ/vf5g=; b=CNCH2ACy/aMQTeK8fD1/H6s6iM3lO2pEW3J5w0jpH0Hg3xAGQT7h+qX/boGRNvU3ME qi3m486Q59YK/VwVObg1BXtW37uBAPSWCW49x/EAkkM/wTosHEQdAEE+A9pQcXwCSzUR UmEeqavAQQs873Bxu0VZEAW8A0k12V8nsngojbXVfV1THcM2H2NHHlchb1NhJU0IsCB/ InmVaDC/wckLCATm+IZy8TNzE5ue46RavIFm4GEBHKLyIgj4WmmGMERxAV2ujTYmQ9H/ R8RSmI3X9HzUx59Hg6FbQU63a9/YTvE7FJ77DTXrS730L69UyOH6plvnz1EnUko53Yid ZBFw== X-Gm-Message-State: AOAM530hhqhsuxVjcldY4vx/ElW0IFAWq8e1ffSvyRqZd7DnM8PxeBwa asPtLdEg5R/h/uE4Vhx9DTl4jyLhwA8X+uiiybM= X-Google-Smtp-Source: ABdhPJy1SsxvPPZfyegfE3KPyDDP0BQylFTAW4qtj/4LSmGm/STkAeTjAj208J4Kk0Tmd1qgKaW+5knKyVuUEqpLF/U= X-Received: by 2002:a0c:a5c5:: with SMTP id z63mr18343764qvz.16.1627316639357; Mon, 26 Jul 2021 09:23:59 -0700 (PDT) MIME-Version: 1.0 From: Daniel Migault Date: Mon, 26 Jul 2021 12:23:48 -0400 Message-ID: To: Erik Kline Cc: lwip@ietf.org, IPsecME WG Content-Type: multipart/alternative; boundary="00000000000039deff05c8092ec8" Archived-At: Subject: [IPsec] minimal esp 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, 26 Jul 2021 16:24:07 -0000 --00000000000039deff05c8092ec8 Content-Type: text/plain; charset="UTF-8" Hi Erik, Thanks for the review which I believe the draft version 06 addresses them. Please find the details inline below. Yours, Daniel [abstract] [nit] * "Some constrains include" -> "Some constraints include" > done [S1] [comment] * Someone will inevitably point out that requirements terminology don't belong in an Informational document. Suggest removing this and lowercase all the terms throughout the document. I know it doesn't seem ideal, but I don't think it really lowers the value of any of the recommendations in the doc. > I am a bit surprised by such a rule. While I might be missing the rationale, but it seems to me that informational documents are also concerned with interoperability and the 2119 language has been introduced to make implementation interoperable. At least that was my understanding. That said, I proceeded as follows: SHOULD NOT: 2 SHOULD: 1 MUST NOT: 3 MUST: 10 RECOMMENDED: 10 MAY: 3 and committed in case we need to reverse it back ;-) [S2] [nit] * "and limited traffic flow confidentiality" seems to be redundant with "provide confidentiality" earlier in the sentence. (It also raises the question of "in what way is it limited?", which just seems like an unnecessary digression.) > limited traffic flow confidentiality in fact designates some padding and the feature is often designated as TFC. It is defined in RFC4303 section 2.7 and the section title mentions padding, so I "padding" was missing, and I also added the acronyme TFC. so the final text is: "and limited traffic flow confidentiality (TFC) padding." I think that addresses the confusion, but we can also point to the specific section of RFC4303. [S3] [nit] * "used internal" -> "used internally" > done * ", checks does not fall" -> "and checks it does not fall" > done [S3.1] [question] * "proceed to clean key update" What does this mean? "clean"? > "clean key" update means that there is a mechanism that enables a peer to say which key is being used. In other words, there is not a set a keys to test. I propose the following change. OLD: SPI can typically be used to proceed to clean key update and the SPI value may be used to indicate which key is being used. This can typically be implemented by a SPI being encoded with the Security Association Database (SAD) entry on a subset of bytes (for example 3 bytes), while the remaining byte is left to indicate the rekey index. NEW: SPI can typically be used to implement a key update with the SPI indicating the key is being used. For example, a SPI might be encoded with the Security Association Database (SAD) entry on a subset of bytes (for example 3 bytes), while the remaining byte indicates the rekey index. * "use of randomly generated SPI" -> "use of randomly generated SPIs" > done * "leakage or privacy or security related information" -> "leakage of privacy or security related information" > done [S4] [question] * When too many packets are dropped (due to "out of window" conditions), does this cause the session to be renegotiated? > SN is checked as the first operation- prior integrity check. If taken into account, these could easily be used to trigger the rekey. In fact the consecutive failed authentication is used to trigger a rekey. RFC 4303, does not mandate any other parameters than consecutive authentication failure to be considered for the trigger, but does not prevent others to be considered and it is worth noticing that out of windows SN are auditable events. So I think that suggesting to consider out of windows event are a bit out of scope of the minimal esp implementation. That said, we may add that when removing the mechanism we should consider that additional integrity checks might be performed. I suggest the following text: OLD: As a result, some implementations MAY drop a non required anti replay protection especially when the necessary resource involved overcomes the benefit of the mechanism. NEW: As a result, some implementations MAY drop a non required anti replay protection especially when the necessary resource involved overcomes the benefit of the mechanism. These resources need also to balance that absence of anti-replay mechanism, may lead to unnecessary integrity check operations that might be significantly more expensive as well. If so, is it important to weight the computational impact of reestablishing IPsec crypto state relative to trying to maintain better record of the previously seen SNs? [S4] [nit] * "drop an non required anti replay protection" -> "drop a non-required anti-replay protection" > done * "the support ESN is not" -> "the support of ESN is not" >done [S5] [nit] * "that were rely on" -> "that were relying on" > done * "rather when" -> "rather than when" > done [S6] [nit] * "generate and receive dummy packet" -> "generate and receive dummy packets" > done * "fix value" -> "fixed value" > done ( 2 times) [S8] [nit] * "provided as indicative" -> "provided as information"? > done: provided as informational * "Constraint devices" -> "Constrained devices" > done * "energy associated to it" -> "energy associated with it" > done [S10] [nit] * "associated to the management" -> "associated with the management" > done * "This usually include mechanisms to prevent a nonce to repeat for example." "This usually includes mechanisms to prevent a nonce from repeating, for example." > done * "in conjunction of" -> "in conjunction with" > done * "responsible to negotiate" -> "responsible for negotiating" -- Daniel Migault Ericsson --00000000000039deff05c8092ec8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Erik,=C2=A0

Thanks for th= e review which=C2=A0I believe the=C2=A0draft version 06 addresses them. Ple= ase find the details inline below.=C2=A0

Yours,=C2= =A0
Daniel

[abstract] [nit]

* "S= ome constrains include" -> "Some constraints include"
=
> done

[S1] [comment]

* Someone will inevitably= point out that requirements terminology
=C2=A0 don't belong in an I= nformational document.

=C2=A0 Suggest removing this and lowercase al= l the terms throughout the
=C2=A0 document.=C2=A0 I know it doesn't = seem ideal, but I don't think it
=C2=A0 really lowers the value of a= ny of the recommendations in the doc.

> I am a bit surprised=C2= =A0by such a rule. While I might be missing the rationale, but it seems to = me that informational documents are also concerned with interoperability an= d the 2119 language=C2=A0 has been introduced to make implementation intero= perable. At least that was my understanding.=C2=A0 That said, I proceeded a= s follows:=C2=A0
SHOULD NOT: 2
SHOULD: 1
MUST= NOT: 3
MUST: 10
RECOMMENDED: 10
MAY: 3
=

and committed=C2=A0in case we need to reverse it back ;= -)

[S2] [nit]

* "and limited traffic flow confide= ntiality" seems to be redundant
=C2=A0 with "provide confident= iality" earlier in the sentence.

=C2=A0 (It also raises the que= stion of "in what way is it limited?",
=C2=A0 which just seems= like an unnecessary digression.)

>=C2=A0limite= d traffic flow confidentiality in fact designates some padding and the feat= ure is often designated as TFC. It is defined in RFC4303 section 2.7 and th= e section title mentions padding, so I "padding" was missing, and= I also added the acronyme=C2=A0TFC. so the final text is:

=C2=A0"and limited traffic flow confidentiality (TFC) padd= ing."

<= /span>
I think that address= es the confusion, but we can also point to the specific section of RFC4303.= =C2=A0
=C2=A0

[S3] [nit]

* "used intern= al" -> "used internally"
> done
* ", checks= does not fall" -> "and checks it does not fall"
> = done

[S3.1] [question]

* "proceed to clean key up= date"

=C2=A0 What does this mean? =C2=A0"clean"?
<= br>> "clean key" update means that there is a mechanism that e= nables a peer to say which key is being used. In other words, there is not = a set a keys to test.=C2=A0 I propose the following change.

<= /div>
OLD:
SPI can typically be used to proceed to clean key = update and the SPI value may be used to indicate which key is being used.
This can typically be implemented by a SPI being encoded with = the Security Association Database (SAD) entry on a subset of bytes (for exa= mple 3 bytes), while the remaining byte is left to indicate the rekey index= .

NEW:
SPI can typically be used to = implement a key update with the SPI indicating the key is being used. =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0
For example, a SPI might be encoded with the Security Associatio= n Database (SAD) entry on a subset of bytes (for example 3 bytes), while th= e remaining byte indicates the rekey index.=C2=A0 =C2=A0 =C2=A0

* "use of randomly generated SPI" ->
=C2=A0 "us= e of randomly generated SPIs"
> done

* "leaka= ge or privacy or security related information" ->
=C2=A0 "l= eakage of privacy or security related information"
> done
<= div>
[S4] [question]

* When too many packets are dropped (due to = "out of window" conditions),
=C2=A0 does this cause the sessio= n to be renegotiated?

> SN is checked as the fi= rst operation- prior integrity check. If taken into account, these could ea= sily be used to trigger the rekey. In fact the consecutive failed authentic= ation is used to trigger a rekey. RFC 4303, does not mandate any other para= meters than consecutive authentication failure to be considered for the tri= gger, but does not prevent others to be considered and it is worth noticing= that out of windows SN are auditable events.=C2=A0 So I think that suggest= ing to consider out of windows event are a bit out of scope of the minimal = esp implementation. That said, we may add that when removing the mechanism = we should consider that additional integrity=C2=A0checks might be performed= .=C2=A0 =C2=A0

I suggest the following text:
=

OLD:
As a result, some implementations MAY drop a= non required anti replay protection especially when the necessary r= esource involved overcomes the benefit of the mechanism.=C2=A0=C2=A0

= NEW:
=C2=A0As a result, some implementations MAY drop a non required anti replay prot= ection especially when the nec= essary resource involved overcomes the benefit of the mechanism. These reso= urces need also to balance that absence of anti-replay mechanism, may lead = to unnecessary integrity check operations that might be significantly more = expensive as well.=C2=A0=C2=A0

=C2=A0 If so, is it important to weight th= e computational impact of
=C2=A0 reestablishing IPsec crypto state relat= ive to trying to maintain
=C2=A0 better record of the previously seen SN= s?

[S4] [nit]

* "drop an non required anti replay protec= tion" ->
=C2=A0 "drop a non-required anti-replay protection= "
> done
* "the support ESN is not" -> "the= support of ESN is not"
>done

[S5] [nit]

* = "that were rely on" -> "that were relying on"
>= ; done
* "rather when" -> "rather than when"
&= gt; done

[S6] [nit]

* "generate and receive dummy= packet" ->
=C2=A0 "generate and receive dummy packets"= ;
> done
* "fix value" -> "fixed value"
= > done ( 2 times)

[S8] [nit]

* "provided as in= dicative" -> "provided as information"?
> done: pro= vided as informational
* "Constraint devices" -> "Cons= trained devices"
> done
* "energy associated to it"= -> "energy associated with it"
> done

[S1= 0] [nit]

* "associated to the management" -> "asso= ciated with the management"
> done

* "This us= ually include mechanisms to prevent a nonce to repeat
=C2=A0 for example= ."

=C2=A0 "This usually includes mechanisms to prevent a n= once from repeating,
=C2=A0 for example."
> done
* "in conjunction of" -> "in conjunction with"
= > done

* "responsible to negotiate" -> "= responsible for negotiating"
--
= Daniel Migault
Ericsson
--00000000000039deff05c8092ec8-- From nobody Mon Jul 26 15:45: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 EA4003A07E1 for ; Mon, 26 Jul 2021 15:45:14 -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, RCVD_IN_DNSWL_BLOCKED=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 (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 d8PfxQ9MUpkX for ; Mon, 26 Jul 2021 15:45:12 -0700 (PDT) Received: from meesny.iki.fi (meesny.iki.fi [IPv6:2001:67c:2b0:1c1::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92EE03A07F2 for ; Mon, 26 Jul 2021 15:45:06 -0700 (PDT) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen@iki.fi) by meesny.iki.fi (Postfix) with ESMTPSA id 153F6200BF for ; Tue, 27 Jul 2021 01:44:59 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1627339499; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Sv27F7ptunQtqqR7peT88I8TZIih61FbR2it8/EW6wA=; b=VzX2ZT2mWqPJdj2uxvtshWhxjGocvWfp0nwwQvLyC7e7TLEnpcj5qZ1L2ELdOkCo1N+vzS roUCtWGqOdqX0TaZ2EZQVEdEuGfPx9fm/Fmwxilk3kWosn7gf5QK1xJzRDOu47pXLuQOJn 8fOTw+dStqvSWb8NIjrDu9ipRft+QCw= Received: by fireball.acr.fi (Postfix, from userid 15204) id 5020125C12CF; Tue, 27 Jul 2021 01:44:58 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24831.15082.263253.443690@fireball.acr.fi> Date: Tue, 27 Jul 2021 01:44:58 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 1 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1627339499; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Sv27F7ptunQtqqR7peT88I8TZIih61FbR2it8/EW6wA=; b=Dt0gxegzNTymBqd0O9EIjncItPiiLraRbIxRwctVfSZiuliK8AmotV67Ypy+9MriKYC/pN xq0tMyJIu8yZ08bOSRwZWrY00J29abcUTrUyyLDJRVauFnKn/iqdDd+l0LWryZs8adLCts tf0ddlzAnj1NJc93lswRk5C3ESR2Ics= ARC-Seal: i=1; s=meesny; d=iki.fi; t=1627339499; a=rsa-sha256; cv=none; b=tXgphJFJIteK2DZftjIHSA1OWM72ry0JOmdjCSxYESAMatJbx+Kmp+ivOxOrNOt34AlslO EUS7Ivk4D5MPA09bU7QCGSF1Vc1IQ5IKsNqnUkURTba7S2WacST9Y6aIBz0Q9sikF8NQa9 dwMvVhpekNsWPOFLW2EiX+9GLAOT7oY= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: [IPsec] WGLC of draft-ietf-ipsecme-labeled-ipsec 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, 26 Jul 2021 22:45:15 -0000 This is the start of 2 week WGLC on the draft-ietf-ipsecme-labeled-ipsec document, ending 2021-08-10. Please submit your comments to the list, also send a note if you have reviewed the document, so we can see how many people are interested in getting this out. -- kivinen@iki.fi From nobody Mon Jul 26 15:46:11 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 BF46C3A0815 for ; Mon, 26 Jul 2021 15:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 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, RCVD_IN_DNSWL_LOW=-0.7, 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=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 AOJi1mp2jVsg for ; Mon, 26 Jul 2021 15:45:58 -0700 (PDT) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [185.185.170.37]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A84753A07FB for ; Mon, 26 Jul 2021 15:45:54 -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@iki.fi) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 7A0391B000A4 for ; Tue, 27 Jul 2021 01:45:50 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1627339550; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=U6OSzb95EutJqjhC1NYuG7XH7YI7z6KIs1DXgW9kXv8=; b=Ujjc55iGP4/IcGHDZFcrQqmq1nmQFRB78oqi5wTfmg23srDPOiVcUfY0/ydEgWI63LChmc Ejw5HpWIacuX3AoFDuvHO9Kqfw5wSfvA3cO3xaqpMlkvOaGtRRPoSumgtnmL9j33VfdgCF WdlLXXoFqv674hrwC1get+u9GdIuRceG6CyITTusQXy9w+od3BqGJ1e7GvuQGGTI3nc/IJ ogj+zx8YHsBlaVkhNla0ofluZfC5oWwi6vQf6oxlbeEwmg2j1e4YTixLC6ecAZq0s0Qqq7 bkBTIZrfiAYlZ8g7jdViFkprgrHryKolzn55HNPWb8CXbIw9j+u4lHcwvuBoyA== Received: by fireball.acr.fi (Postfix, from userid 15204) id 1196C25C12CF; Tue, 27 Jul 2021 01:45:50 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24831.15134.45575.357305@fireball.acr.fi> Date: Tue, 27 Jul 2021 01:45:50 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 0 min X-Total-Time: 0 min ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1627339550; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=U6OSzb95EutJqjhC1NYuG7XH7YI7z6KIs1DXgW9kXv8=; b=Qv8c8T/3YX1yhUKR6Qz9IY3wclcOZYZLZu+yC6zzrjCA0HgdsaXcUSbnIUFrIy4BLJ+Sas WDIYm1VLmpgUqg8AlqEy3W6/DBuQD3ah7Eo5Hqjr0lgFSLwQRnsu4qCHh6OXHeyfBsvz4A zC+n06V1ubpEcvsuH9VibjYNEvPJYAXUi6YLOBuywdINVYK7rXo99Yl4i9qeLY3oI5bZvw 5aQmbS9aKZ8DZYm4X5izZwA5N7V49+yuVM9K49liNg8OnaYFwb8KQOlB25Q/pkfKZJ4efx w0Ra0EXqbi5wkiyoZucno7G6077GTBhtPL1Xye335lzkw6cKHyu3gsksUCvowA== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1627339550; a=rsa-sha256; cv=none; b=HbbyytdwYsoTUw9oybzfCCI+PemqSW1FSVDtGcjabGE+6VUCqtdIfuquJVU/zCRx7aPqF8 0dqKPCyn7ZFXpazdYMPlsP8xj7vQmUg2DUNH9xqV5KvUk2H2p3u7OMNKcM/dKxt3XaANK1 LbcLCO67eB6WEJl92cH6A+y1qh2Cw/ILhB34RdGXhOHqUDANb+IQBUWsfNxrB2GdTDEKmz OrglUrTEuXYsZi3MOkExe+vRBSJeGho4n0hzK+NnLrtHj4ex0+ubqvBpkMCXrlU6czR5xZ YfXdX95LPTYuZIIY+lCXXDPxW/ya+91jYMDVs637Ejldd3oCJfqLnCMBp4bl5w== Archived-At: Subject: [IPsec] WGLC for draft-ietf-ipsecme-ikev2-multiple-ke 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, 26 Jul 2021 22:46:10 -0000 This is the start of 2 week WGLC on the draft-ietf-ipsecme-ikev2-multiple-ke document, ending 2021-08-10. Please submit your comments to the list, also send a note if you have reviewed the document, so we can see how many people are interested in getting this out. -- kivinen@iki.fi From nobody Mon Jul 26 16:19: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 BBE0D3A09E5 for ; Mon, 26 Jul 2021 16:19: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 5OMoao1X8H_L for ; Mon, 26 Jul 2021 16:19:14 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 ABE383A09DB for ; Mon, 26 Jul 2021 16:19:13 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id z2so18507011lft.1 for ; Mon, 26 Jul 2021 16:19:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=bWrzM2HXPI/nKnrXQOB6h1+HD71/C49XnT9Nhfi7Alw=; b=jXeahuizYh2TmhB2vELfa16efofEDgA/GqiQQlCn8nsXQsrM8B8arYOztHjzK/stfb dOPw8ESwM7OOY6/L2/G0p9lW6Yim7juNhMV1DCVDV1lO1y/S1hfsgTDOk0BTF5q+SWI0 ekGJbOhUbjENmZ6gUboJgTrTxZIpj0AwD9A+zLS9mXJF1Gy2K+u2O/2nFjZLPKXHwZ/E /6GPbu7tkZBC4qPmf+aT3hxAuEy0sAdzSH3S88QHX9mIgb+eP8iD1VI+U+xD9IJrHJLR JXCnfZ/5tfWyhWnavBqZxJAw4KCE/L5pXJK/sX2nbaYW0qkoqXviApX8in05yW4/YGwL A26Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=bWrzM2HXPI/nKnrXQOB6h1+HD71/C49XnT9Nhfi7Alw=; b=hefa6dQlo3F15k8AsZ1PdHzbM5jm7w0YRxOlPXnmC9gtrXBwyxSFnLioFpEzBbIQRH 5VoI/hJyZH+tBg1gezOLB3HyLZoOcHOpdemzZ9RoXjXOoCy82jzAKRZsdUFguZWWxgbi uX1oAB9SE1/+D/J+dsX7NxaxM1vGREA9LG56sFmI1f3Q1iL1D+z53HD7uq3FKc9ZrLSV tot1WkGs3M5gtG5/Mx+0YguFpKmyLyvfvnCDmTQdPPYx3OyhKtpSCW3/MdVFzdVJEMMS 2kKkAqCgdznGiKeish06DTJGVu4E/Ljtg2PwO+Ntuz6YnBALi72No6GwPnBKg1Oj1dn3 c2Zg== X-Gm-Message-State: AOAM531dV3eDIybmXQrUt3iMPOK/kOwMWy6AcQ0cR517WgeY0gSMIHtc rPItF2h/CmYCCLxfUUFND/4F4rdrHDk= X-Google-Smtp-Source: ABdhPJwWnd8DwvSvQpSgJB7cuucKnuedtFHWQdYMBu15gKVIz0iC9myqeEvce/pjLS967xUtRaKpfg== X-Received: by 2002:a19:7101:: with SMTP id m1mr15146433lfc.233.1627341549870; Mon, 26 Jul 2021 16:19:09 -0700 (PDT) Received: from svannotebook (37-144-56-120.broadband.corbina.ru. [37.144.56.120]) by smtp.gmail.com with ESMTPSA id 24sm128515lft.98.2021.07.26.16.19.08 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Jul 2021 16:19:09 -0700 (PDT) From: "Valery Smyslov" To: Date: Tue, 27 Jul 2021 02:19:07 +0300 Message-ID: <006801d78274$a30b8f60$e922ae20$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdeCcgyiH8/r4/ZpQsW47G6aeku1UQ== Content-Language: ru Archived-At: Subject: [IPsec] Temporary codepoints for PQ KEMs 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, 26 Jul 2021 23:19:19 -0000 Hi, as Scott requested at the meeting, I'm sending the list of temporary codepoints for NIST PQ KEMs that were used for interop testing (actually, they were selected by strongSwan): /** NIST round 3 KEM candidates, in PRIVATE USE */ KE_KYBER_L1 = 1050, KE_KYBER_L3 = 1051, KE_KYBER_L5 = 1052, KE_NTRU_HPS_L1 = 1053, KE_NTRU_HPS_L3 = 1054, KE_NTRU_HPS_L5 = 1055, KE_NTRU_HRSS_L3 = 1056, KE_SABER_L1 = 1057, KE_SABER_L3 = 1058, KE_SABER_L5 = 1059, /** NIST alternative KEM candidates, in PRIVATE USE */ KE_BIKE_L1 = 1060, KE_BIKE_L3 = 1061, KE_BIKE_L5 = 1062, KE_FRODO_AES_L1 = 1063, KE_FRODO_AES_L3 = 1064, KE_FRODO_AES_L5 = 1065, KE_FRODO_SHAKE_L1 = 1066, KE_FRODO_SHAKE_L3 = 1067, KE_FRODO_SHAKE_L5 = 1068, KE_HQC_L1 = 1069, KE_HQC_L3 = 1070, KE_HQC_L5 = 1071, KE_SIKE_L1 = 1072, KE_SIKE_L2 = 1073, KE_SIKE_L3 = 1074, KE_SIKE_L5 = 1075 These codepoints are temporary and intended to be used for interops. Regards, Valery. From nobody Tue Jul 27 09:40:04 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 A06173A0908 for ; Tue, 27 Jul 2021 09:40:01 -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, 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=aiven.io 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 aC8KpKw604yY for ; Tue, 27 Jul 2021 09:39:57 -0700 (PDT) Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (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 ADB493A090C for ; Tue, 27 Jul 2021 09:39:56 -0700 (PDT) Received: by mail-ej1-x631.google.com with SMTP id nd39so23123383ejc.5 for ; Tue, 27 Jul 2021 09:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aiven.io; s=google; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=Y18Yfa/9aDVbo6Z5+iNwtjvp95ktsgJsvWzn5HftQag=; b=FePpG7GfBH17ty2ZZg2iUJnaSqvici/k92Le5z8tFwNHQcEvwikbppWApTG2JxFNfV aN77NuFP8leYl9vUdcCEByYXKVgKWTRtweQ5dXaRQ9fZ1jQgKd6nEByQpZC2BN4CrXQM RFT77dHVEJ+9Qvok/DV+iy8atV/s9+XyLWrec= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version; bh=Y18Yfa/9aDVbo6Z5+iNwtjvp95ktsgJsvWzn5HftQag=; b=B9jmUrdm1JBQJKRU54Mjc2EeQS0IWOWFQhPFFqvZQ5Kh30evgUY5eFOpBiethznHY7 rbRqRXEOstHbpjXVtl5Rx6I/8KYl2hAlZm5SSkA81N/ZKso3eS3SzNI+1qxLKb92rN3i dLjVcp+GgELlCjqA1+9uTAGkd1uOI7RwQP4vkLAq/HK3Bv5u9rjfcq1yBb0jfmgui7XC GduOhc5CfLSCkBmt7aKte8YHAgioS8l+RZDjm+AoJDc2JgISsmRUcSQGxHJoKCcAh0ry lz/r3dvTxo+lmRQWeiO0CBAfVAHHlSsos1+RoeX7UO3H2Z+uBYaI+WMGUcfuYjLlhDyu BQtA== X-Gm-Message-State: AOAM5334vasMih62BsVkXlz2PzyFJxOxluRE0ywKp8cXdbePWluBlkyy gc8BxJ5Wq2bXDmwI2KNkpMGMpQ== X-Google-Smtp-Source: ABdhPJzEbxisw240xMOyl1fIBH7E1wODoXhIucgGdEKYHN8LTgo+XOeZf0byWfoDQn7rQpkC5v5PoQ== X-Received: by 2002:a17:906:5292:: with SMTP id c18mr11399009ejm.308.1627403993612; Tue, 27 Jul 2021 09:39:53 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca. [193.110.157.194]) by smtp.gmail.com with ESMTPSA id l17sm1463752edt.52.2021.07.27.09.39.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Jul 2021 09:39:53 -0700 (PDT) Date: Tue, 27 Jul 2021 12:39:49 -0400 (EDT) From: Paul Wouters To: Tero Kivinen cc: "ipsec@ietf.org WG" In-Reply-To: <24831.15134.45575.357305@fireball.acr.fi> Message-ID: <6bca2d7d-a061-148b-bbdb-1783e72a936@nohats.ca> References: <24831.15134.45575.357305@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev2-multiple-ke 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, 27 Jul 2021 16:40:02 -0000 On Tue, 27 Jul 2021, Tero Kivinen wrote: > Subject: [IPsec] WGLC for draft-ietf-ipsecme-ikev2-multiple-ke > > This is the start of 2 week WGLC on the > draft-ietf-ipsecme-ikev2-multiple-ke document, ending 2021-08-10. Note that this document has a prerequisite on the intermediate exchange, so even if it passed WGLC/IETF LC before intermediate exchange, it will have to wait in an RFC Editor cluster for the other draft. > Please submit your comments to the list, also send a note if you have > reviewed the document, so we can see how many people are interested in > getting this out. I have reviewed the document. In general I support this document. I really like the idea of renaming the DH Registry to KE. I do think it is not ready yet though. My comments and questions follow below. Key exchange methods negotiated via Transform Type 4 MUST always take place in the IKE_SA_INIT exchange. Additional key exchanges negotiated via newly defined transforms MUST take place in a series of IKE_INTERMEDIATE exchanges, in an order of the values of their transform types, so that key exchange negotiated using Transform Type n always precedes that of Transform Type n + 1. I don't understand this section, specifically the use of "Transform Type 4" and "Transport Type n+1", as we only have transform type 5 and nothing higher and that is Extended Sequence Number. https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-8 I think it might be trying to say if there are more than one Key Exchange, that the subsequent key exchange should follow in the next IKE message exchange (eg in a round of IKE_INTERMEDIATE) ? Each IKE_INTERMEDIATE exchange MUST bear exactly one key exchange method. I don't understand why there is this limitation. What if some Key Exchange mechanism will require 2 RTTs. Why preventively forbid that? Additional key exchange methods are proposed using Additional Key Exchanges transform types. All these transform types are optional, the initiator is free to select any of them for proposing additional key exchange methods. Consequently, if none of Additional Key Exchange transforms are included in the proposal, then this proposal indicates performing standard IKEv2, as defined in [RFC7296]. So how does an intiiator convey that it deems an additional Key Exchange to be mandatory? If the initiator includes any transform of type n (where n is among Additional Key Exchanges) in the proposal, the responder MUST select one of the algorithms proposed using this type. A transform ID NONE may be added to those transform types which contain key exchange methods that the initiator believes are optional. And so I again do not understand this. What is "n" here? a new transform type ? ( eg n=6 ??) or a new entry in the Transform Type 4 Key Exchange registry? At his point, the Additional Key Exchange is introduced, and I am beginning to understand things. This should really be explained before the text I pointed at above to make any sense to the reader. And see below on placing "Additional Key Exchanges" into the "Key Exchanges" Registry. The next part explains the CREATE_CHILD_SA and IKE_FOLLOWUP_KE exchanges. I personally would prefer that a different exchange than CREATE_CHILD_SA is used if the completion of such an exchange does not lead to a fully rekeyed state. This use of completing a CREATE_CHILD_SA and being in a state that is not "rekeyed" or "failed" complicates the state machine. Each IKE_FOLLOWUP_KE exchange MUST bear exactly one key exchange method. See above. Why this preventative limitation? The data associated with this notification is a blob meaningful only to the responder Why a blob? Why not the imminent new SPI it generated for this new IKE SA? If you really want a blob, there should be an example of how to generate the blobs. I don't see any such guidance in the document. Below is an example of three additional key exchanges. Initiator Responder --------------------------------------------------------------------- HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi} --> <-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr, N(ADDITIONAL_KEY_EXCHANGE)(link1)} Why does the initiator not start out with a N(ADDITIONAL_KEY_EXCHANGE) ? There has been an Additional Key Exchange in the initial exchanges, so why not start out with one in the rekey from the initiator? What would an initiator do if the responder omited N(ADDITIONAL_KEY_EXCHANGE) ? It has given no indication it might be mandatory from the initiator's point of view. It is possible that due to some unexpected events (e.g. reboot) the initiator could forget that it is in the process of performing additional key exchanges and never starts next IKE_FOLLOWUP_KE exchanges. The responder MUST handle this situation gracefully And wouldn't that solve this weird state issue if the initiator already signalled this clearly in CREATE_CHILD_SA, so the responder could in that case already return an error in the CREATE_CHILD_SA exchange? Note that I find the argument weird, why would an IKE peer forget some of its state after a reboot? Both peers should always remember AKE's were used and have to be used again upon (PFS) rekeys. it MUST send back a new error type notification STATE_NOT_FOUND. This is a non-fatal error notification [...] If the initiator receives this notification in response to IKE_FOLLOWUP_KE exchange performing additional key exchange, it MUST cancel this exchange and MUST treat the whole series of exchanges started from the CREATE_CHILD_SA exchange as failed. So why use a non-fatal error notification that leads to a guaranteed failure ? Note there seems to be a notion of AKE's having continuous state, as opposed to (EC)DH where you start a new state with the rekey exchange. Perhaps this should be clarified at the beginning of the document? This document adds the following Transform Types to the "Transform Type Values" registry: Type Description Used In ----------------------------------------------------------------- Additional Key Exchange 1 (optional in IKE, AH, ESP) Additional Key Exchange 2 (optional in IKE, AH, ESP) Additional Key Exchange 3 (optional in IKE, AH, ESP) Additional Key Exchange 4 (optional in IKE, AH, ESP) Why are the descriptions referring to "additional" key exchange? I would assume the registry is just a list of Key Exchange types, and whether one of these is "additional" or not depends on its use in IKE ? That is, one of the Key Exchanges that today is "additional" might one day be used as the only Key Exchange without Additional Key Exchanges? If we really are making some of these exchanges as "additional use only", then we should really create a new transform type registry for AKE that is separate from the Key Exchange Type (4). the key lengths of these transforms SHALL be at least 256 bits long in order to provide sufficient resistance to quantum attacks. I would use MUST instead of SHALL. The main focus of this document is to prevent a passive attacker performing a "harvest and decrypt" attack. In other words, an attacker that records messages exchanges today and proceeds to decrypt them once he owns a quantum computer. This attack is prevented due to the hybrid nature of the key exchange. Other attacks involving an active attacker using a quantum-computer are not completely solved by this document. This is for two reasons. I think this part and the text right underneath this belongs in the Introduction more than it belongs in the Security Considerations section. Unfortunately, this design is susceptible to the following downgrade attack. I'm not convinced this is an issue actually. If you really do think a proper configuration would not sufficiently protect against this, the initiator could send a notify in the second IKE_SA_INIT of the rejected KE value from the previous response, so that this attack would be detected. We discarded this approach because we believe that the working group may not be happy using the RESERVED field to change the format of a packet and that implementers may not like the complexity added from checking the fragmentation flag in each received payload. I think that is exactly why we have RESERVED fields. As implementer, I don't think that this would have been too complex. But I think using INTERMEDIATE is fine, especially if multiple solutions can use this method for their own usage, and having a generic method is better than having specific methods per postquantum/hybrid solution. Nits: a typo: CRETE_CHILD_SA this side MUST not initiate -> this side MUST NOT initiate Paul From nobody Tue Jul 27 20:16:49 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 AD6953A18E9 for ; Tue, 27 Jul 2021 20:16:47 -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, 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=aiven.io 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 jlIKawsIxohU for ; Tue, 27 Jul 2021 20:16:43 -0700 (PDT) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 219943A18E6 for ; Tue, 27 Jul 2021 20:16:42 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id x90so1211944ede.8 for ; Tue, 27 Jul 2021 20:16:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aiven.io; s=google; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=sLgMqnyrodPD4E50Bv8eu9iOCFeodg42etXuYmoyQu4=; b=AvxG+L1A5Hgw8ozfhRFYnm5EHZaA/6XDiBPC/wnfhkXRznqtHcw0kmXY3JGkuDzUuN A/5zA1TA0AmuawE0CAmjzkvmfvTJhpgLsbaWzchqqjX+/MI6bB2yax9hrW1+nAGxsP3X rZ1eV+FCdcLni3C4aM/4VvQ8o19u92ru5cJyM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version; bh=sLgMqnyrodPD4E50Bv8eu9iOCFeodg42etXuYmoyQu4=; b=PQZ7XZYeqXC5PQpvpugPrV4FeETlQdNQfUsvW7N7cbLjRag/1hjalM/ljmwLJ9zj0S Ik6r38ZkzVcLdZHtv1W5TNYT9JIIZ3iQGPymRjle5vxzFH61AtqF47tpn08RX7/SxB5w AU4HujN+uH5+ZVs87AWwt5DP3ObLbkBhMvOSeGh4STcbXRMDm7HUZDeZw4ov3fUjFFka t1udWm9O2H0L9RrCH9v3lDx2KpN0CaBeSc42ppjYzWaDDTNrJq2OUkWHPEASAL+rAiRf 48204TzX8ykRY9rIS05/1YrzZerftrDcSSJ9YSARVBEsn5mwpBWOk9QQN2Wz8UB61m9P YuNg== X-Gm-Message-State: AOAM531g2GWqW4yeat1QHSwVknSTHzpt3e9YJZCuFHDHlBq1eiML3/2t FRNZOucYylpoxTkpCdTw34oIgQ== X-Google-Smtp-Source: ABdhPJzhpjLDsZbHvna+YCaJuf5uA6ZOFiqNU4r8jXbmWPTH/L+wyvKuF3oyhnpWfDjggEqiN8FZ5w== X-Received: by 2002:a05:6402:1396:: with SMTP id b22mr31398227edv.380.1627442201236; Tue, 27 Jul 2021 20:16:41 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca. [193.110.157.194]) by smtp.gmail.com with ESMTPSA id ks26sm1152112ejb.58.2021.07.27.20.16.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Jul 2021 20:16:41 -0700 (PDT) Date: Tue, 27 Jul 2021 23:16:36 -0400 (EDT) From: Paul Wouters To: Tero Kivinen cc: "ipsec@ietf.org WG" In-Reply-To: <24831.15082.263253.443690@fireball.acr.fi> Message-ID: <59cd35e-9972-7a1c-dcad-16c0b3d61ba8@nohats.ca> References: <24831.15082.263253.443690@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [IPsec] WGLC of draft-ietf-ipsecme-labeled-ipsec 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, 28 Jul 2021 03:16:48 -0000 On Tue, 27 Jul 2021, Tero Kivinen wrote: > This is the start of 2 week WGLC on the > draft-ietf-ipsecme-labeled-ipsec document, ending 2021-08-10. > > Please submit your comments to the list, also send a note if you have > reviewed the document, so we can see how many people are interested in > getting this out. I'm an author, so obviously I am interested. Also, the code point is allocated so I think we are beyond the point of meassuring "interest" :) But it would be good to know if the document has any issues, since we can then still fix them. We also have an implementation (libreswan with Linux). Note that the IKE negotiation part of labels was pretty straightforward. The Linux SElinux labels implementation is not. I will likely write up an informational draft about the Linux kernel implementation and usage. Paul From nobody Wed Jul 28 01:57:14 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 A206F3A23FF for ; Wed, 28 Jul 2021 01:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 fs2adkxfWmm2 for ; Wed, 28 Jul 2021 01:57:09 -0700 (PDT) Received: from mail.strongswan.org (sitav-80046.hsr.ch [152.96.80.46]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89EB43A23FE for ; Wed, 28 Jul 2021 01:57:08 -0700 (PDT) Received: from [IPv6:2a01:8b81:5407:c100:40b4:5172:f25f:bb77] (unknown [IPv6:2a01:8b81:5407:c100:40b4:5172:f25f:bb77]) by mail.strongswan.org (Postfix) with ESMTPSA id 99EE640AA7; Wed, 28 Jul 2021 10:57:06 +0200 (CEST) To: Paul Wouters , Tero Kivinen Cc: "ipsec@ietf.org WG" References: <24831.15134.45575.357305@fireball.acr.fi> <6bca2d7d-a061-148b-bbdb-1783e72a936@nohats.ca> From: Tobias Brunner Message-ID: <05108315-d094-ccfb-4a61-a3b1c1f46317@strongswan.org> Date: Wed, 28 Jul 2021 10:57:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <6bca2d7d-a061-148b-bbdb-1783e72a936@nohats.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev2-multiple-ke 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, 28 Jul 2021 08:57:13 -0000 Hi Paul, Trying to clarify some things from my experience implementing this extension. The authors might have some more insights on these points. > Key exchange methods negotiated via Transform Type 4 MUST always take > place in the IKE_SA_INIT exchange. Additional key exchanges > negotiated via newly defined transforms MUST take place in a series > of IKE_INTERMEDIATE exchanges, in an order of the values of their > transform types, so that key exchange negotiated using Transform Type > n always precedes that of Transform Type n + 1. > > I don't understand this section, specifically the use of "Transform Type 4" > and "Transport Type n+1", as we only have transform type 5 and nothing > higher and that is Extended Sequence Number. The documents defines additional transform types for the additional key exchanges. > I think it might be trying to say if there are more than one Key Exchange, > that the subsequent key exchange should follow in the next IKE message > exchange (eg in a round of IKE_INTERMEDIATE) ? They should, but the exchanges should also be performed in order. So if e.g. algorithms for Additional Key Exchange 1 and Additional Key Exchange 2 are negotiated, the key exchange for Additional Key Exchange 1 has to be done before the one for Additional Key Exchange 2. > Each IKE_INTERMEDIATE exchange MUST bear exactly one key exchange method. > > I don't understand why there is this limitation. What if some Key > Exchange mechanism will require 2 RTTs. Why preventively forbid that? That would be a new type of key exchange that couldn't be used with IKEv2 as it is currently defined (neither for IKE nor Child SAs). But I think you misunderstood. What the above means is that you can't send two KE payloads in a single IKE_INTERMEDIATE exchange (i.e. you can't send the KE paylaods for Additional Key Exchange 1 and Additional Key Exchange 2 if algorithms were negotiated for both). > Additional key exchange methods are proposed > using Additional Key Exchanges transform types. All these transform > types are optional, the initiator is free to select any of them for > proposing additional key exchange methods. Consequently, if none of > Additional Key Exchange transforms are included in the proposal, then > this proposal indicates performing standard IKEv2, as defined in > [RFC7296]. > > So how does an intiiator convey that it deems an additional Key Exchange > to be mandatory? It proposes the respective transform type without adding NONE. What the above means is that the initiator can freely choose to propose e.g. Additional Key Exchange 1, but not Additional Key Exchange 2 and 3, and Additional Key Exchange 4 (for whatever reason, maybe each transform type is somehow linked to a specific class of algorithms in this implementation and it only has some of them available). Or it can also not propose any of them or include NONE in some or all of them to leave it up to the responder if a specific key exchange is performed. > If the initiator includes any transform of type n (where > n is among Additional Key Exchanges) in the proposal, the responder > MUST select one of the algorithms proposed using this type. A > transform ID NONE may be added to those transform types which contain > key exchange methods that the initiator believes are optional. > > And so I again do not understand this. What is "n" here? a new transform > type ? ( eg n=6 ??) or a new entry in the Transform Type 4 Key Exchange > registry? Yes, a new transform type (Additional Key Exchange 1-7), not a new entry in the registry for transform type 4. > At his point, the Additional Key Exchange is introduced, and I am > beginning to understand things. This should really be explained before > the text I pointed at above to make any sense to the reader. And see > below on placing "Additional Key Exchanges" into the "Key Exchanges" > Registry. I see :) > The next part explains the CREATE_CHILD_SA and IKE_FOLLOWUP_KE exchanges. I > personally would prefer that a different exchange than CREATE_CHILD_SA > is used if the completion of such an exchange does not lead to a fully > rekeyed state. This use of completing a CREATE_CHILD_SA and being in a > state that is not "rekeyed" or "failed" complicates the state machine. Until the proposals are negotiated during the CREATE_CHILD_SA exchange, the initiator doesn't know if any new mechanisms or exchanges are needed. And because a PQ-safe IKE_SA protects the negotiation of additional CHILD_SAs or their rekeying, classic key exchanges could be considered perfectly safe for those if forward secrecy is desired. > The data associated with this notification is a blob meaningful only to the responder > > Why a blob? Why not the imminent new SPI it generated for this new IKE SA? > If you really want a blob, there should be an example of how to generate > the blobs. I don't see any such guidance in the document. As the text says, it's a completely arbitrary blob of data. So you could use the allocated SPI if that's helpful to you. In my implementation (with Window Size 1) I just use a static, single-byte value as it really doesn't matter. > Below is an example of three additional key exchanges. > > Initiator Responder > --------------------------------------------------------------------- > HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi} --> > <-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr, > N(ADDITIONAL_KEY_EXCHANGE)(link1)} > > > Why does the initiator not start out with a N(ADDITIONAL_KEY_EXCHANGE) ? > There has been an Additional Key Exchange in the initial exchanges, so > why not start out with one in the rekey from the initiator? Because this notify is only for the responder to associate IKE_FOLLOWUP_KE requests with the state it created for the original CREATE_CHILD_SA exchange. As mentioned above, it's basically irrelevant for implementations with Windows Size 1, but if that's not the case, the initiator might initiate multiple CREATE_CHILD_SA exchanges concurrently and that might result in multiple IKE_FOLLOWUP_KE requests that the responder later has to associate with the correct states. > What would an initiator do if the responder omited N(ADDITIONAL_KEY_EXCHANGE) ? > It has given no indication it might be mandatory from the initiator's point of view. It's mandatory from the protocol's point of view. I guess the behavior could be clarified (e.g. demand that the initiator sends an INVALID_SYNTAX notify in a new INFORMATIONAL exchange). > It is possible that due to some unexpected events (e.g. reboot) the > initiator could forget that it is in the process of performing > additional key exchanges and never starts next IKE_FOLLOWUP_KE > exchanges. The responder MUST handle this situation gracefully > > And wouldn't that solve this weird state issue if the initiator already > signalled this clearly in CREATE_CHILD_SA, so the responder could in > that case already return an error in the CREATE_CHILD_SA exchange? > Note that I find the argument weird, why would an IKE peer forget some > of its state after a reboot? Both peers should always remember AKE's > were used and have to be used again upon (PFS) rekeys. It's not about the configs but the runtime state. Your implementation doesn't persist all the IKE and IPsec SAs and their state during a reboot, right? So it's similar to half-open IKE_SAs where the initiator might never send an IKE_AUTH (or IKE_INTERMEDIATE) message because it rebooted or there was a network issue. Because the operation initiated by the CRATE_CHILD_SA request is not complete with sending the CREATE_CHILD_SA response if additional KEs are used, the responder is in a situation where it might wait for an IKE_FOLLOWUP_KE request indefinitely. However, I'm not sure if there is any benefit in setting a timer and only removing the state associated with the CREATE_CHILD_SA exchange as it seems unlikely to me that the initiator would only lose the state for a single such exchange and later initiate a different exchange on the same IKE_SA. So maybe removing the complete IKE_SA might be the better approach (or just don't do anything and rely on DPDs initiated by the server to resolve this). > it MUST send back a new error type notification STATE_NOT_FOUND. > This is a non-fatal error notification > [...] > If the initiator receives this notification in > response to IKE_FOLLOWUP_KE exchange performing additional key > exchange, it MUST cancel this exchange and MUST treat the whole > series of exchanges started from the CREATE_CHILD_SA exchange as > failed. > > So why use a non-fatal error notification that leads to a guaranteed failure ? "non-fatal" refers to the IKE_SA. The operation (rekey or Child SA creation) initiated by the CREATE_CHILD_SA request is aborted but can get restarted if deemed necessary by the initiator. But as mentioned above, I'm not entirely sure if the timeout set on individual CREATE_CHILD_SA exchange states makes sense. > Note there seems to be a notion of AKE's having continuous state, as > opposed to (EC)DH where you start a new state with the rekey exchange. > Perhaps this should be clarified at the beginning of the document? Where do you get that from? > This document adds the following Transform Types to the "Transform > Type Values" registry: > > Type Description Used In > ----------------------------------------------------------------- > Additional Key Exchange 1 (optional in IKE, AH, ESP) > Additional Key Exchange 2 (optional in IKE, AH, ESP) > Additional Key Exchange 3 (optional in IKE, AH, ESP) > Additional Key Exchange 4 (optional in IKE, AH, ESP) > > > Why are the descriptions referring to "additional" key exchange? I would > assume the registry is just a list of Key Exchange types, and whether > one of these is "additional" or not depends on its use in IKE ? That is, > one of the Key Exchanges that today is "additional" might one day be > used as the only Key Exchange without Additional Key Exchanges? If we > really are making some of these exchanges as "additional use only", then > we should really create a new transform type registry for AKE that is > separate from the Key Exchange Type (4). They are additional to the default key exchange with transform type 4. Since the algorithms for all of these are from the same registry (that for transform type 4) there is nothing (except maybe IP fragmentation) preventing you from using new PQ-safe algorithms with transform type 4 during IKE_SA_INIT. So it's not that any algorithms are considered additional it's the key exchanges negotiated with those transform types. Regards, Tobias From nobody Wed Jul 28 04:01:54 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 D42073A07E0; Wed, 28 Jul 2021 04:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIX0dZ8giaQL; Wed, 28 Jul 2021 04:01:51 -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 D363F3A07D9; Wed, 28 Jul 2021 04:01:50 -0700 (PDT) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen@iki.fi) by meesny.iki.fi (Postfix) with ESMTPSA id 5942B200C0; Wed, 28 Jul 2021 14:01:14 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1627470074; 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; bh=tNTx+pznFkUAOlW35YP1ntzLvfja7FBxv9tAJti3IDY=; b=bym7u8YEnC0uXjZAwcTeEalY7Fp8i+gZeGV2v/8xhUBYitUxWSucsdN7KEBmpdfQtliA/l H6KjieeP3xn1qr/JiZ5oCt3jINhefIluZM1ImL2S/JRNh3cXdouS7Aid4jARaR/UTf3gZB kyeWPrBv2FhYKxRPlWK3viW7CxtM7cE= Received: by fireball.acr.fi (Postfix, from userid 15204) id 1E29B25C12CA; Wed, 28 Jul 2021 14:01:14 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24833.14586.64495.521033@fireball.acr.fi> Date: Wed, 28 Jul 2021 14:01:14 +0300 From: Tero Kivinen To: ipsec@ietf.org CC: draft-ietf-ipsecme-ikev2-intermediate@ietf.org X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 24 min X-Total-Time: 24 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1627470074; 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; bh=tNTx+pznFkUAOlW35YP1ntzLvfja7FBxv9tAJti3IDY=; b=tHa5HTT/qpQZKHJ9/mN8PpI9vH/YwAL5xN42SvR1eRJ2rNQt+Knoet2oZJVjC28q8SF/vN oih94vPfy3Yh9688J7Vj/7nJzhm3H+1bdF+rMtMsv7DB52QK/pTjimyv0VxyQsFoDoo3ai xO88QRazwJqcp0UauhH0mdxN8BCoD0Y= ARC-Seal: i=1; s=meesny; d=iki.fi; t=1627470074; a=rsa-sha256; cv=none; b=i1phQxIWAtEpBJKDQOVLn1M1eOIhsWS0eTIvSDC647YdOxK9KtxAilOpbK6V66naAWxyj2 e52DYBZAeA3RPI8/4JLbmElE37K3lRDc07VZgmnWwnsrx5pyCdDnMezTIj5VddvCdbjnNE v7n1lkdbNcUE1bh8/VAtOyZFlL+MOWY= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: [IPsec] Few comments to draft-ietf-ipsecme-ikev2-intermediate 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, 28 Jul 2021 11:01:53 -0000 I was reading the draft-ietf-ipsecme-ikev2-intermediate through and I think it might be good thing to add a note at the end of section 3.3.1 Protection of the IKE_INTERMEDIATE messages to clarify which SK_e[i/r] and SK_a[i/r] are to be used for the IKE_AUTH after all IKE_INTERMEDIATE exchanges (I assume it is the latest one). Also perhaps we should have appendix showing the full protocol exchange example. I.e. something like this: ---------------------------------------------------------------------- Appendix A. Example of IKE_INTERMEDIATE exchange. This appendix contains a short example of the messages using IKE_INTERMEDIATE. This appendix is purely informative; if it disagrees with the body of this document, the other text is considered correct. In this example there is one IKE_SA_INIT exchange, two IKE_INTERMEDIATE key exchanges followed by the IKE_AUTH exchange to authenticate the exchange. The xxx in the HDR(xxx,MID=yyy) indicates the exchange type, and yyy tells the message id used for that exchange. The keys used for each SK {} payload is indicated in the parenthesis after the SK. Otherwise payload notation is same as is used in the RFC7296. Initiator Responder ------------------------------------------------------------------- HDR(IKE_SA_INIT,MID=0), SAi1, KEi, Ni, N(INTERMEDIATE_EXCHANGE_SUPPORTED) --> <-- HDR(IKE_SA_INIT,MID=0), SAr1, KEr, Nr, [CERTREQ], N(INTERMEDIATE_EXCHANGE_SUPPORTED) HDR(IKE_INTERMEDIATE,MID=1), SK(SK_ei_1,SK_ai_1) { ... } --> <-- HDR(IKE_INTERMEDIATE,MID=1), SK(SK_er_1,SK_ai_1) { ... } HDR(IKE_INTERMEDIATE,MID=2), SK(SK_ei_2,SK_ai_2) { ... } --> <-- HDR(IKE_INTERMEDIATE,MID=2), SK(SK_er_2,SK_ai_2) { ... } HDR(IKE_AUTH,MID=3), SK(SK_ei_3,SK_ai_3) {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} --> <-- HDR(IKE_AUTH,MID=3), SK(SK_er_3,SK_ar_3) {IDr, [CERT,] AUTH, SAr2, TSi, TSr} ---------------------------------------------------------------------- I think having such appendix would make things easier to understand. -- kivinen@iki.fi From nobody Fri Jul 30 05:36:40 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 E4EF23A28BC; Fri, 30 Jul 2021 05:36:38 -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 K_iu20IXjYzB; Fri, 30 Jul 2021 05:36:34 -0700 (PDT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 6F7C63A28BA; Fri, 30 Jul 2021 05:36:34 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id l34-20020a05600c1d22b02902573c214807so3663406wms.2; Fri, 30 Jul 2021 05:36:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=MZfV5XDxXfJtcISlJwWG4v2mBWFa0ZVnOakfMItI9QE=; b=l3Zn1hjLzEKssUoFKqNid5FSEwE19DSGvhnQ4vPBkoNf8w/H9H8MsswefuO9TVKkKW 6Z5bBhK1NbBAzhBGqXM7he3KdASKnNObKNpbRXOcYaIcn5+aRSbPiQ7JkrrR2JOi8VyE 2opikQUXMTCFBa6d9eRKOswW6Fnp886CuhUnM/yeR+SuhRYRKxBAsdsuYzzoFYvNW51M KH5+cUsCMV5sSbC5g6MoseIEt32vMzZ0vpEuH1wOYOiAhYQ4H5m27mRuw+1NyiJ1F7WS 2xQZnH12jfqwib9M+baU7R4YknP1m/q17YnLmUXw2+/rldN1MGdRUTpBqo/UKdry04bh 8MCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=MZfV5XDxXfJtcISlJwWG4v2mBWFa0ZVnOakfMItI9QE=; b=XE5a83Pr0SBGuL7xRIX8D1bB0rBDmjluH2muo/vqyadbgVAHlIWl+vqvN9IFvapGSn yhsLB6InA7F1ysJjMdli+Bxv9zWt0Ui7QDu70ynI1Pux32ggKbIxVRyOym8vkanJsSu7 7rNvzVw6EQ7eod/ST+GOZOdSib4opnMTZcHOZHPFbMdkxUgPeIiYr6ZbJ7XKE02MQ4al /2uumYlQs0tIXWRCNgSOe2Re4NaL9sRm79pm7BH8C7u5pw1SU0j9a543aK5AyA9ebn0b lRL0oORLzH1oDoo+aCTyBgMw0VvnDzN9lkDVPbocSh3VYuHLsb8EDySYhU2H4fcmyfrL XwvQ== X-Gm-Message-State: AOAM531OOtDm2Syhv+rY7UmU0tRZI5DZLeLW8RUgO9kPmjM6Vd6rEPv3 FfhmiFzxcTyILdlpMKkM7zkuijhY0nQ= X-Google-Smtp-Source: ABdhPJyhzUE6vik6CvHAkJ608VwNKBQJXLpU+BHnbcjyyLCGcNPc8U2lOoTo41k3kU6CcQc1CLQycw== X-Received: by 2002:a1c:2504:: with SMTP id l4mr2701523wml.55.1627648591108; Fri, 30 Jul 2021 05:36:31 -0700 (PDT) Received: from buildpc ([93.188.44.204]) by smtp.gmail.com with ESMTPSA id v5sm1704943wrd.74.2021.07.30.05.36.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Jul 2021 05:36:30 -0700 (PDT) From: "Valery Smyslov" To: "'Tero Kivinen'" , Cc: References: <24833.14586.64495.521033@fireball.acr.fi> In-Reply-To: <24833.14586.64495.521033@fireball.acr.fi> Date: Fri, 30 Jul 2021 15:36:32 +0300 Message-ID: <1cac01d7853f$8817e460$9847ad20$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJQKrEZ54quEJwBN/sMC9jC/FvMbapqJiKw Content-Language: ru Archived-At: Subject: Re: [IPsec] Few comments to draft-ietf-ipsecme-ikev2-intermediate 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, 30 Jul 2021 12:36:39 -0000 Hi Tero, > I was reading the draft-ietf-ipsecme-ikev2-intermediate through and I > think it might be good thing to add a note at the end of section 3.3.1 > Protection of the IKE_INTERMEDIATE messages to clarify which SK_e[i/r] > and SK_a[i/r] are to be used for the IKE_AUTH after all > IKE_INTERMEDIATE exchanges (I assume it is the latest one). Your assumption is correct. I can add the following text at the end of 3.3.1: Once all IKE_INTERMEDIATE exchanges are completed, the most recently calculated SK_e[i/r] and SK_a[i/r] keys are used for protection of the IKE_AUTH and all the subsequent exchanges. Are you OK with this? > Also perhaps we should have appendix showing the full protocol > exchange example. I.e. something like this: > > ---------------------------------------------------------------------- > > Appendix A. Example of IKE_INTERMEDIATE exchange. > > This appendix contains a short example of the messages using > IKE_INTERMEDIATE. This appendix is purely informative; if it > disagrees with the body of this document, the other text is > considered correct. > > In this example there is one IKE_SA_INIT exchange, two > IKE_INTERMEDIATE key exchanges followed by the IKE_AUTH exchange to > authenticate the exchange. The xxx in the HDR(xxx,MID=yyy) > indicates the exchange type, and yyy tells the message id used for > that exchange. The keys used for each SK {} payload is indicated in > the parenthesis after the SK. Otherwise payload notation is same as > is used in the RFC7296. > > > Initiator Responder > ------------------------------------------------------------------- > HDR(IKE_SA_INIT,MID=0), > SAi1, KEi, Ni, > N(INTERMEDIATE_EXCHANGE_SUPPORTED) --> > > <-- HDR(IKE_SA_INIT,MID=0), > SAr1, KEr, Nr, [CERTREQ], > N(INTERMEDIATE_EXCHANGE_SUPPORTED) > > using them for SK {} payloads> > > HDR(IKE_INTERMEDIATE,MID=1), > SK(SK_ei_1,SK_ai_1) { ... } --> > > > > <-- HDR(IKE_INTERMEDIATE,MID=1), > SK(SK_er_1,SK_ai_1) { ... } > > > > SK_[aip][ir] and store them as SK_[aip][ir]_2, start using them for > SK {} payloads> > > HDR(IKE_INTERMEDIATE,MID=2), > SK(SK_ei_2,SK_ai_2) { ... } --> > > > > <-- HDR(IKE_INTERMEDIATE,MID=2), > SK(SK_er_2,SK_ai_2) { ... } > > > > SK_[aip][ir] and store them as SK_[aip][ir]_3, start using them for > SK {} payloads> > > HDR(IKE_AUTH,MID=3), > SK(SK_ei_3,SK_ai_3) {IDi, > [CERT,] [CERTREQ,] > [IDr,] AUTH, SAi2, > TSi, TSr} --> > > <-- HDR(IKE_AUTH,MID=3), > SK(SK_er_3,SK_ar_3) {IDr, > [CERT,] AUTH, > SAr2, TSi, TSr} > > ---------------------------------------------------------------------- > > I think having such appendix would make things easier to understand. OK, will add it. Thank you, Valery. > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Jul 30 08:37:41 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 3426F3A2E8D for ; Fri, 30 Jul 2021 08:37:31 -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=unavailable 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 29V9cKpkZ0Gb for ; Fri, 30 Jul 2021 08:37:26 -0700 (PDT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 F34AC3A2DF4 for ; Fri, 30 Jul 2021 08:37:14 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id f14-20020a05600c154eb02902519e4abe10so9439876wmg.4 for ; Fri, 30 Jul 2021 08:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=k2jlfJvjm2gxYtAI2dN6bKuJ4Z8tA8ZOLAAmvEzmSy4=; b=EViNECu2OSMF09iWX8eqp9DJUtX60x2xpVcC/PlVklhaoF1EhsLIOAHgR5cR7O9sZG 6N2qrcXgMYN1mQdoDfsGLyIfOivAKqbNOS0q5qj27N2B++91MVrkp9JvBMiuoGt3wqGi KdPizrjXuCqdFOkDhHzWlPvhyqHJK+2DlZCoivQBnHDhrFQN4qEGfAsAXbQGYsf5DkE7 4wN1CxQT7QN8mlQilqWfnZ60VZIPlF4wApCXWzca83IWDfAckPf7VjZmoX/U9s6I+mCo dgRl+chWzWS349Ie+7IoxkNbI3MceEYCGNpDLXzVrZ+n9N0Cpxzt92Bmpz0bNxgiuDPQ ofQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=k2jlfJvjm2gxYtAI2dN6bKuJ4Z8tA8ZOLAAmvEzmSy4=; b=EN05NfMMHO6gRoB2MzroKw1094jjDRssqPWiis5KIGU0PC4L/0i40FMdLCEDpP8VW4 4EQBGBukbEbSSsvkg1dHlBY+s6qhpZ455LHKoKOj7CATRR2KleIALbXZJTgwHfMENGQ2 FPrvlxNjdboUh5bQhEc0qJ7Q4dbEbalXeEC/kMyj7d1jmo4FkYzX8NxVpFH7xzz5cTmJ Mq+uYRr6KgEadqfP89zdsvm2JofktwMPYZl5zhzbfMGWrcfKVeBmjZbSWFUeNF6Z4gyw ORCXjAG+gomaQFqQARCkGCjnILa+75Lm2oBQmqEM5DPI4XITUCH8m9w27dasBqnyJEUN u1nw== X-Gm-Message-State: AOAM533N8WZdMzeCV4UdO8XF+W9brh6PbTQ6vZiCR0As/Qbh2zYpGTae GsgiCroZ1wLmBihX7un6h38yMGyTRJY= X-Google-Smtp-Source: ABdhPJwR52S7Us00e4EjcOVS4R+FPPE+u34bdxo0dXJLSkTINed+g+Av88QUtzAS4IR2DooKCIbRjw== X-Received: by 2002:a05:600c:190e:: with SMTP id j14mr3390865wmq.19.1627659427938; Fri, 30 Jul 2021 08:37:07 -0700 (PDT) Received: from buildpc ([93.188.44.204]) by smtp.gmail.com with ESMTPSA id b14sm2089740wrm.43.2021.07.30.08.37.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Jul 2021 08:37:07 -0700 (PDT) From: "Valery Smyslov" To: "'Paul Wouters'" , "'Tero Kivinen'" Cc: References: <24831.15134.45575.357305@fireball.acr.fi> <6bca2d7d-a061-148b-bbdb-1783e72a936@nohats.ca> In-Reply-To: <6bca2d7d-a061-148b-bbdb-1783e72a936@nohats.ca> Date: Fri, 30 Jul 2021 18:37:10 +0300 Message-ID: <1ced01d78558$c3696700$4a3c3500$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHSSxvHYdJQTTTsbhaUF9nQ+n6JMQIHkjKzq1WoxrA= Content-Language: ru Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev2-multiple-ke 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, 30 Jul 2021 15:37:40 -0000 Hi Paul, thank you for the review. Please find my comments inline. > > This is the start of 2 week WGLC on the > > draft-ietf-ipsecme-ikev2-multiple-ke document, ending 2021-08-10. > > Note that this document has a prerequisite on the intermediate exchange, > so even if it passed WGLC/IETF LC before intermediate exchange, it will > have to wait in an RFC Editor cluster for the other draft. I see no problem here. Actually, it was expected :-), for this reason the intermediate exchange draft was sent to LC earlier, so that it would be ahead of multiple ke draft. Unfortunately, things slowed down a bit, but it is still ahead. > > Please submit your comments to the list, also send a note if you have > > reviewed the document, so we can see how many people are interested in > > getting this out. > > I have reviewed the document. In general I support this document. I > really like the idea of renaming the DH Registry to KE. I do think it > is not ready yet though. My comments and questions follow below. > > Key exchange methods negotiated via Transform Type 4 MUST always take > place in the IKE_SA_INIT exchange. Additional key exchanges > negotiated via newly defined transforms MUST take place in a series > of IKE_INTERMEDIATE exchanges, in an order of the values of their > transform types, so that key exchange negotiated using Transform Type > n always precedes that of Transform Type n + 1. > > I don't understand this section, specifically the use of "Transform Type 4" > and "Transport Type n+1", as we only have transform type 5 and nothing > higher and that is Extended Sequence Number. A one para above new Transform Types are introduced: Additional Key Exchange 1, Additional Key Exchange 2, Additional Key Exchange 3, etc. Once added to IANA registry, they will get their numbers (hopefully in an order of their names). The text is trying to say, that when additional KE are being negotiated, the order in which they will take place is defined by the order of assigned Transform Types (which will correspond to the order of their names). In other words, if at the end of negotiation peers decided that they will perform base KE (negotiated via Transform Type 4, which this draft renames to "Key Exchange Method (KE)") 2048-bit MODP Group, and two additional Key Exchanges - SIKE_P434, negotiated in "Additional Key Exchange 3" transform, and FRODOKEM_640_AES, negotiated in "Additional Key Exchange 5" transform, then they agree to use 2048-bit MODP Group in the IKE_SA_INIT, then SIKE_P434 in the first IKE_INTERMEDIATE followed IKE_SA_INIT and FRODOKEM_640_AES in the next IKE_INTERMEDIATE. If, for example, they negotiated the same group in Transform Type 4, but two additional Key Exchanges - SIKE_P434, negotiated in "Additional Key Exchange 4" transform, and FRODOKEM_640_AES, negotiated in "Additional Key Exchange 1" transform, then they will perform 2048-bit MODP Group in the IKE_SA_INIT, then FRODOKEM_640_AES in the first IKE_INTERMEDIATE followed IKE_SA_INIT and SIKE_P434 in the next IKE_INTERMEDIATE. > https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-8 > > I think it might be trying to say if there are more than one Key Exchange, > that the subsequent key exchange should follow in the next IKE message > exchange (eg in a round of IKE_INTERMEDIATE) ? It is implied here (and defined in Section 3.1). But the real message here is that the order of key exchanges performed in a sequence of IKE_INTERMEDIATE is defined by the order of "Additional Key Exchange *" transforms via which they are negotiated. > Each IKE_INTERMEDIATE exchange MUST bear exactly one key exchange method. > > I don't understand why there is this limitation. What if some Key > Exchange mechanism will require 2 RTTs. Why preventively forbid that? We didn't consider such exotic key exchange methods and, I think, if they appear, they will deserve a separate document. But the real message here is that you cannot perform several key exchanges using a single IKE_INTERMEDIATE exchange. In other words, you cannot put several public keys of different Key Exchange methods in a single IKE_INTERMEDIATE message. > Additional key exchange methods are proposed > using Additional Key Exchanges transform types. All these transform > types are optional, the initiator is free to select any of them for > proposing additional key exchange methods. Consequently, if none of > Additional Key Exchange transforms are included in the proposal, then > this proposal indicates performing standard IKEv2, as defined in > [RFC7296]. > > So how does an intiiator convey that it deems an additional Key Exchange > to be mandatory? If the initiator includes "Additional Key Exchange N" transform, then the responder MUST choose a single method from those included in this transform. If the list of included methods doesn't contain NONE, then the responder have to choose one of them, so performing this KE method is mandatory. To make it optional the initiator includes NONE among other methods. This allows the responder to select NONE and thus to skip doing this additional KE. > If the initiator includes any transform of type n (where > n is among Additional Key Exchanges) in the proposal, the responder > MUST select one of the algorithms proposed using this type. A > transform ID NONE may be added to those transform types which contain > key exchange methods that the initiator believes are optional. > > And so I again do not understand this. What is "n" here? a new transform > type ? ( eg n=6 ??) or a new entry in the Transform Type 4 Key Exchange > registry? n here is new Transform Type. We define "Additional Key Exchange 1", "Additional Key Exchange 2", "Additional Key Exchange 3" ... up to "Additional Key Exchange 7". > At his point, the Additional Key Exchange is introduced, and I am > beginning to understand things. This should really be explained before > the text I pointed at above to make any sense to the reader. And see > below on placing "Additional Key Exchanges" into the "Key Exchanges" > Registry. Actually, the new transforms are introduced in 3.2.1, but I see your point and probably we should add more clarifications before this section. (I also noted that Additional Key Exchange transforms are mentioned at the end of 3.1 before their formal introduction, that must be fixed). > The next part explains the CREATE_CHILD_SA and IKE_FOLLOWUP_KE exchanges. I > personally would prefer that a different exchange than CREATE_CHILD_SA > is used if the completion of such an exchange does not lead to a fully > rekeyed state. This use of completing a CREATE_CHILD_SA and being in a > state that is not "rekeyed" or "failed" complicates the state machine. That's true. However, there is a tradeoff here. If you defined a new two-message exchange, that performed multiple key exchange methods at once, then the initiator would include public keys for all KE methods it proposed which is terrible for performance reasons, since the responder may reject most of them. The message size is also would grow dramatically, and in case the responder selected a tiny subset of what was proposed, this would be extremely inefficient. > Each IKE_FOLLOWUP_KE exchange MUST bear exactly one key exchange method. > > See above. Why this preventative limitation? Again, for simplicity it is prohibited to perform several key exchanges in a single IKE exchange (IKE_INTERMEDIATE or IKE_FOLLOWUP_KE). > The data associated with this notification is a blob meaningful only to the responder > > Why a blob? Why not the imminent new SPI it generated for this new IKE SA? > If you really want a blob, there should be an example of how to generate > the blobs. I don't see any such guidance in the document. The purpose of this data blob is to allow the responder to link CREATE_CHILD_SA and subsequent IKE_FOLLOWUP_KE between themselves in case the initiator creates several Child SAs (or rekeys them, or rekeys IKE SA) simultaneously. In this situation the following sequence is plausible: Initiator Responder --------------------------------------------------------------------- HDR(CREATE_CHILD_SA), SK {SA, Ni, Kei, TSi, TSr} --> <-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr, TSi, TSr N(ADDITIONAL_KEY_EXCHANGE)(link01)} at this point some event triggers the initiator to start another CREATE_CHILD_SA, while the first sequence is not complete yet: HDR(CREATE_CHILD_SA), SK {SA, Ni, Kei, TSi, TSr } --> <-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr, TSi, TSr N(ADDITIONAL_KEY_EXCHANGE)(link11)} note, that without any additional means the responder at this point is unable to say whether next IKE_FOLLOWUP_KE belongs to the first CREATE_)CHILD_SA ir to the second. To make it possible the responder sends back ADDITIONAL_KEY_EXCHANGE with some blob only meaningful to it, that allows it to link the incoming IKE_FOLLOWUP_KE with proper CREATE_CHILD_SA. HDR(IKE_FOLLOWUP_KE), SK {KEi(2), N(ADDITIONAL_KEY_EXCHANGE)(link11)} --> <-- HDR(IKE_FOLLOWUP_KE), SK {KEr(2)} HDR(IKE_FOLLOWUP_KE), SK {KEi(1), N(ADDITIONAL_KEY_EXCHANGE)(link01)} --> <-- HDR(IKE_FOLLOWUP_KE), SK {KEr(1)} The draft doesn't give any advice of how to generate this blob, because it's a local matter of responder. > Below is an example of three additional key exchanges. > > Initiator Responder > --------------------------------------------------------------------- > HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi} --> > <-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr, > N(ADDITIONAL_KEY_EXCHANGE)(link1)} > > > Why does the initiator not start out with a N(ADDITIONAL_KEY_EXCHANGE) ? > There has been an Additional Key Exchange in the initial exchanges, so > why not start out with one in the rekey from the initiator? Because N(ADDITIONAL_KEY_EXCHANGE)(data blob) is for the responder to allow it to properly link IKE_FOLLOWUP_KE with this particular CREATE_CHILD_SA. At the time initiator sends CREATE_CHILD_SA request it doesn't know yet what to put into (data blob) of ADDITIONAL_KEY_EXCHANGE. Note, that this data may be dynamic and is completely unrelated to the data blob sent in previous exchanges. > What would an initiator do if the responder omited N(ADDITIONAL_KEY_EXCHANGE) ? If the responder omits N(ADDITIONAL_KEY_EXCHANGE) then from its point of view no more IKE_FOLLOWUP_KE is expected in the context of this CREATE_CHILD_SA. If from responder point of view they negotiated more additional key exchanges than were performed, then it should be treated in the same way, as if some mandatory payload is absent (e.g. the responder omitted KE payload in CREATE_CHILD_SA when some key exchange is negotiated). I think it's a fatal error. > It has given no indication it might be mandatory from the initiator's point of view. You are right, this must be clarified in the draft. > It is possible that due to some unexpected events (e.g. reboot) the > initiator could forget that it is in the process of performing > additional key exchanges and never starts next IKE_FOLLOWUP_KE > exchanges. The responder MUST handle this situation gracefully > > And wouldn't that solve this weird state issue if the initiator already > signalled this clearly in CREATE_CHILD_SA, so the responder could in > that case already return an error in the CREATE_CHILD_SA exchange? Sorry, I didn't follow your idea. Can you elaborate? > Note that I find the argument weird, why would an IKE peer forget some > of its state after a reboot? Both peers should always remember AKE's > were used and have to be used again upon (PFS) rekeys. It's true, but in this case the initiator forgets that it started CREATE_CHILD_SA (with AKEs) before reboot. In this case it never continues this sequence after rebooting and restoring last stable IKE SA state. > it MUST send back a new error type notification STATE_NOT_FOUND. > This is a non-fatal error notification > [...] > If the initiator receives this notification in > response to IKE_FOLLOWUP_KE exchange performing additional key > exchange, it MUST cancel this exchange and MUST treat the whole > series of exchanges started from the CREATE_CHILD_SA exchange as > failed. > > So why use a non-fatal error notification that leads to a guaranteed failure ? Because the failure may be recoverable - just start new CREATE_CHILD_SA with AKEs. I see no need to delete IKE SA in this case. Of course, if the failure persisted after several attempts, then the only thing peer can do - delete SA. > Note there seems to be a notion of AKE's having continuous state, as > opposed to (EC)DH where you start a new state with the rekey exchange. > Perhaps this should be clarified at the beginning of the document? Can you please provide text candidate? > This document adds the following Transform Types to the "Transform > Type Values" registry: > > Type Description Used In > ----------------------------------------------------------------- > Additional Key Exchange 1 (optional in IKE, AH, ESP) > Additional Key Exchange 2 (optional in IKE, AH, ESP) > Additional Key Exchange 3 (optional in IKE, AH, ESP) > Additional Key Exchange 4 (optional in IKE, AH, ESP) > > > Why are the descriptions referring to "additional" key exchange? I would > assume the registry is just a list of Key Exchange types, and whether > one of these is "additional" or not depends on its use in IKE ? That is, > one of the Key Exchanges that today is "additional" might one day be > used as the only Key Exchange without Additional Key Exchanges? If we > really are making some of these exchanges as "additional use only", then > we should really create a new transform type registry for AKE that is > separate from the Key Exchange Type (4). Additional here means that KE methods negotiated via these transforms are always performed in addition to KE method, negotiated via Transform Type 4. All these transform types share the same registry of Transform IDs with Transform Type 4. Note, that these transform types have different semantics than other IKEv2 transforms - they don't concern with own algorithm type (they all are concerned with KE methods), they only allow to negotiate which KE methods perform additionally to a base KE method and in which order. If one day you don't need to perform additional key exchanges then just don't use these transforms. > the key lengths of these > transforms SHALL be at least 256 bits long in order to provide > sufficient resistance to quantum attacks. > > I would use MUST instead of SHALL. OK. > The main focus of this document is to prevent a passive attacker > performing a "harvest and decrypt" attack. In other words, an > attacker that records messages exchanges today and proceeds to > decrypt them once he owns a quantum computer. This attack is > prevented due to the hybrid nature of the key exchange. Other > attacks involving an active attacker using a quantum-computer are not > completely solved by this document. This is for two reasons. > > I think this part and the text right underneath this belongs in the > Introduction more than it belongs in the Security Considerations > section. This probably makes sence. I'll discuss this with my co-authors. > Unfortunately, this design is susceptible to the following > downgrade attack. > > I'm not convinced this is an issue actually. If you really do think a > proper configuration would not sufficiently protect against this, the > initiator could send a notify in the second IKE_SA_INIT of the rejected > KE value from the previous response, so that this attack would be > detected. I won't comment on this - this is just an appendix with early design alternatives. I'll let my co-authors to comment on this. > We discarded this approach because we believe that the working > group may not be happy using the RESERVED field to change the > format of a packet and that implementers may not like the > complexity added from checking the fragmentation flag in each > received payload. > > I think that is exactly why we have RESERVED fields. As implementer, I > don't think that this would have been too complex. But I think using > INTERMEDIATE is fine, especially if multiple solutions can use this > method for their own usage, and having a generic method is better than > having specific methods per postquantum/hybrid solution. OK, we are in agreement :-) > Nits: > > a typo: CRETE_CHILD_SA > > > this side MUST not initiate -> this side MUST NOT initiate Will fix, thanks. Thank you again for thorough review. Regards, Valery. > Paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec