From nobody Sun Aug 1 12:42: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 A6CA43A0B0A; Sun, 1 Aug 2021 12:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.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=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 7ybjtr78v4jQ; Sun, 1 Aug 2021 12:42:31 -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 E0A193A0B09; Sun, 1 Aug 2021 12:42:30 -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 lahtoruutu.iki.fi (Postfix) with ESMTPSA id 517231B00245; Sun, 1 Aug 2021 22:42:28 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1627846948; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=H2x3t5sJpKto2Iyul0I4yMrdExVBz2FXkG3G0dWsRzQ=; b=NFHeR5cPLiz4R7u2rWDOmWTeGUu7JW6/nYLu5Bzi697i9xA5RCKlRf3Zn8n6YlActF9KM8 JVVjUGO2K9V9BY97umNFgC0B8PecD1nnxKnlL6gpeG03cj+V6C3tcnJkQcqL2aIRdD38oh zDDiv0UDljP2wMOHBSucM5dFQUS2EkORFaWHUgCsXjzHZpDgUNT1/WMWhvy1/EXLc2UFW8 OoDzWXuBedZ6qz41x61ehCd41+Vc9XeButif/vGOQUlMSeyxedvzONDQigp+E8gOgH9s41 BhLeo/eDQdu9RT0IwsGU5IEmD4FnLzM3yoIMr3Ki95uZlByX/pNHh+dq24c7Tg== Received: by fireball.acr.fi (Postfix, from userid 15204) id D358A25C12D0; Sun, 1 Aug 2021 22:42:27 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24838.63779.831896.747620@fireball.acr.fi> Date: Sun, 1 Aug 2021 22:42:27 +0300 From: Tero Kivinen To: "Valery Smyslov" Cc: , draft-ietf-ipsecme-ikev2-intermediate@ietf.org In-Reply-To: <1cac01d7853f$8817e460$9847ad20$@gmail.com> References: <24833.14586.64495.521033@fireball.acr.fi> <1cac01d7853f$8817e460$9847ad20$@gmail.com> 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=1627846948; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=H2x3t5sJpKto2Iyul0I4yMrdExVBz2FXkG3G0dWsRzQ=; b=DkeKytHmWbRwhOctwFRB/rIX/8uYko1KB4Twe4/kCOnb9pG+BH0FcQAKLErmN9G4MvEv/2 kCMBaVi08D1gll7QhNExNvI3U2D3F2TUgo4dF/i0yx+ybbD+Wtb6/4Pl963qKwaSjF6vQM PAY7W6RSDI3vCGvGGEMKfZem9pLoj1mDVMbB1eVkiojclpbs179mzHGA058LhYyPpK2dv7 VQg7sRhi5pemv8GDEP4EQF6oWBhbY5kTdVvF0p2AQXhpB9cxNv0JdgdJXbQo5aG8csI1/j fkyenj1fkpxwL7Lm8LCDQqFZIpM2gk/bJ9dO9WN89PYTvLF9pt76Yd04rgeQWw== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1627846948; a=rsa-sha256; cv=none; b=D0uzwPXVBzAWcW3lgmBV4I/qfhSmhwt2l5oRERZhB8437UhwMAgtw4BSBsT6A09JS5MyDE CxZqMzWyv2x8wGJAXBkCxt1SKKSSCeb0flx9KfAbZaVX/CRKjMc1Ih/JveLZ89EEH/FAvr l6x7glvorkSF1wmntSGukIuN86/clNaxXtY1r0hYUhNoo/raUpzxBzFABZ7IU1xYZ1NEam ETHVdpqk4s8Cn5dyYRhW/tj06Sg0YzAhNnAVhy1wpYy6xaxPt/cJyub/dt7QnhoWXh9ybk +VhXY/JsyA7s5YoZ3JeYH154TJBhre0AJxZCpEtm2CNYs3t4dhGXhONBQ2kNCg== 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: Sun, 01 Aug 2021 19:42:34 -0000 Valery Smyslov writes: > 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? Looks good for me. > > 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. Thanks. Just make sure you read it through and verify that my understanding of the exchange process was correct. -- kivinen@iki.fi From nobody Tue Aug 3 08:08:05 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 B234B3A26B1; Tue, 3 Aug 2021 08:07:53 -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.35.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <162800327364.26338.16165349200188311486@ietfa.amsl.com> Date: Tue, 03 Aug 2021 08:07:53 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-intermediate-07.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, 03 Aug 2021 15:07:54 -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 : Intermediate Exchange in the IKEv2 Protocol Author : Valery Smyslov Filename : draft-ietf-ipsecme-ikev2-intermediate-07.txt Pages : 13 Date : 2021-08-03 Abstract: This documents defines a new exchange, called Intermediate Exchange, for the Internet Key Exchange protocol Version 2 (IKEv2). This exchange can be used for transferring large amount of data in the process of IKEv2 Security Association (SA) establishment. Introducing Intermediate Exchange allows re-using existing IKE fragmentation mechanism, that helps to avoid IP fragmentation of large IKE messages, but cannot be used in the initial IKEv2 exchange. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-intermediate/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-intermediate-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-intermediate-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 3 08:14:34 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF973A26F0 for ; Tue, 3 Aug 2021 08:14:33 -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 Gn0bpJrQy_4f for ; Tue, 3 Aug 2021 08:14:29 -0700 (PDT) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4694F3A26EC for ; Tue, 3 Aug 2021 08:14:29 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id b11so20372628wrx.6 for ; Tue, 03 Aug 2021 08:14:29 -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=lc449aXy9Dk7zW+t/UJCpgKNQEUb+8L2fjCZ1gDm9q4=; b=oG21zKVzOuDdNa0eL9AVAECufUoHoA8S8NFt+kqR6R/ORYurqbuVhOhn0vDtwCsvPD Kr4f0Myz0mRirPbi5RqDC7VjMepVJLndj/4HRUWzUNi/+CSGsGGanNFPvFsb5wAL49uj lRwhnOobFcjuW7yaSgW4UI5PuUg5koC3e7cAysGT/VXH8agYD3PF6p1LVqvfoN47jDkS Rf68peO8riP73YOtEkbmedr5MDe3Lvs0vSP+CeZ3VClsMdmPvTbsiIkXcaj4VbZLMaMD lWLqLFA5qNl/zazC/CcpxP1uJklKtD0v4+ZyTVWxVFimRbMnwKQKE0N70p1GqEwejbF7 nZ6Q== 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=lc449aXy9Dk7zW+t/UJCpgKNQEUb+8L2fjCZ1gDm9q4=; b=NHqKHyRRB4JkEMxhzye9rMcURbryiOeTIBC1C5XdPm5TuSTcq7BQGt+h8JLXVgzLnu QLLFj2RJW8H1DOsf4bAoN2RozRuSPH1+Tn5d4QmdwYVllxpZulRAT9LmPeg9kTq/jqP5 eX1/WrVwUpYntZi0VTndXAvTy8LLinKUqKhHAorIUFRBaScx2Wu697nYnVZnrLS7RoE+ aWZjci2S8YvfppklIp8GUaNl8QDEKgfyhlgDa+xgoo+AjD4+I/oMFBk7W3bppndGZo9F tjMW+5t92xyikk8qaY2vf6L9PH/hI+bFcBwprqChmtMBeTd+R1QX2XP3Ys5eX1SE32XE S3fQ== X-Gm-Message-State: AOAM531R73/z2xcw84Uvm4D7gfMPdMGS4F0YfHDvOn5xgmM5JQzzBc4C Wcfk0ug9oYo0r5f8n4bgfSNDeq0Vaxg= X-Google-Smtp-Source: ABdhPJy425KaRAQFL7gCItKFO/U94YJyCcmSci9JZcJC/Q9p+twIrkeJwi0vKNBfOwGrnTSt8QVeiQ== X-Received: by 2002:a05:6000:1106:: with SMTP id z6mr24024006wrw.296.1628003666838; Tue, 03 Aug 2021 08:14:26 -0700 (PDT) Received: from buildpc ([93.188.44.204]) by smtp.gmail.com with ESMTPSA id q17sm14830062wre.3.2021.08.03.08.14.26 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Aug 2021 08:14:26 -0700 (PDT) From: "Valery Smyslov" To: References: <162800327364.26338.16165349200188311486@ietfa.amsl.com> In-Reply-To: <162800327364.26338.16165349200188311486@ietfa.amsl.com> Date: Tue, 3 Aug 2021 18:14:26 +0300 Message-ID: <200401d7887a$404d62c0$c0e82840$@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: AQKJoE8K6iRmOb3gkaBTqOHjnoL5Kan9so0Q Content-Language: ru Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-intermediate-07.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2021 15:14:34 -0000 Hi, I just posted a new version of the IKE intermediate draft. It addresses comments from Tero: 1. Added a clarification about keys for IKE_AUTH. 2. Added an Appendix containing example of using IKE_INTERMEDIATE exchange. 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 : Intermediate Exchange in the IKEv2 Protocol > Author : Valery Smyslov > Filename : draft-ietf-ipsecme-ikev2-intermediate-07.txt > Pages : 13 > Date : 2021-08-03 > > Abstract: > This documents defines a new exchange, called Intermediate Exchange, > for the Internet Key Exchange protocol Version 2 (IKEv2). This > exchange can be used for transferring large amount of data in the > process of IKEv2 Security Association (SA) establishment. > Introducing Intermediate Exchange allows re-using existing IKE > fragmentation mechanism, that helps to avoid IP fragmentation of > large IKE messages, but cannot be used in the initial IKEv2 exchange. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-intermediate/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-intermediate-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-intermediate-07 > > > 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 Wed Aug 4 22:31:08 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 5A3FC3A0B20; Wed, 4 Aug 2021 22:31:06 -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.399, SPF_HELO_NONE=0.001, SPF_NONE=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 cOGqQwQrdDZ3; Wed, 4 Aug 2021 22:31:01 -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 4B6813A0B18; Wed, 4 Aug 2021 22:31:01 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1755UpjY029663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 5 Aug 2021 01:30:57 -0400 Date: Wed, 4 Aug 2021 22:30:51 -0700 From: Benjamin Kaduk To: Paul Wouters Cc: Tero Kivinen , "ipsec@ietf.org WG" Message-ID: <20210805053051.GG50759@kduck.mit.edu> References: <24831.15082.263253.443690@fireball.acr.fi> <59cd35e-9972-7a1c-dcad-16c0b3d61ba8@nohats.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <59cd35e-9972-7a1c-dcad-16c0b3d61ba8@nohats.ca> 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: Thu, 05 Aug 2021 05:31:07 -0000 On Tue, Jul 27, 2021 at 11:16:36PM -0400, Paul Wouters wrote: > 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. I am not 100% sure, but I think the NFSv4 WG might be interested to hear about such a document as well. There was some controversy about one of the nfsv4 documents and whether it could proceed without some stable definition of what the linux labels actually mean. -Ben From nobody Mon Aug 9 06:01: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 B2E723A0FDC for ; Mon, 9 Aug 2021 06:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, 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 X0sux3oO2K0O for ; Mon, 9 Aug 2021 06:01:08 -0700 (PDT) Received: from esg-sm.forcepoint.com (esg-sm3.forcepoint.com [204.15.67.173]) (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 A923F3A0FDD for ; Mon, 9 Aug 2021 06:01:07 -0700 (PDT) Received: from webmailgov.forcepoint.com (unknown [172.29.172.3]) by Forcepoint Email with ESMTPS id E3FD7736D59D8A0C4044 for ; Mon, 9 Aug 2021 06:01:06 -0700 (PDT) Received: from SRCA019EXCH1B.tcs-sec.com (172.29.172.3) by SRCA019EXCH1B.tcs-sec.com (172.29.172.3) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Mon, 9 Aug 2021 06:01:28 -0700 Received: from USG02-BN3-obe.outbound.protection.office365.us (23.103.199.148) by SRCA019EXCH1B.tcs-sec.com (172.29.172.3) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2 via Frontend Transport; Mon, 9 Aug 2021 06:01:28 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=KuzyqXDSRMnqz+u8C0SMl+ln74mA1T+dKNfs5zjOlHbV2T20CIO9UriToR1y2D/F3Nov21CCtVJddqiiroFLLNClB4GNKkhO9HB3EEeMlXISMDwJUDTjma+VEstgsNJhHNkXsO6cCUQu2/I4q6j8aJSG85dGZDMW1+eK/QMfp6V3DGKurMz41UtKkftHUErIh0tAzhkFeaMF/o93U5AztivneOVkVtIOt2NppMaLtbgxXHhUadkJVCuydMw+80aQtkZymDMBfaYv7NFRKlhuNBf3ZGsEzvbKh7GCotsR6BHrDs2349+RTmfZa5HLi2mwUTB4QIeBqFVov6Q3BiuZdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AgKLLXXqEcs+CfzyvvQAqxv4Tc2F/2TB8f9ZmFA7XZM=; b=LsKk9NxmcFbEm++SYX5XoSqbITyUVnClMDcxrKjtHJwuTnk0aDTqcjwy7XO5UG7r3M8HDq8q0W+W65sZp5hoqr9MC8sWTiY41DhqdyXHA3Jl/DItfBPP92KFRPLRwSONsUF+zlS3aBwmK495lyarT6DgBkNfu76+tMrvuONKpXNlTC9bnjFFzJql5LQbYRc66Ml+3AmpskJYbiRccJp0ZZSFihW4NYr3BH1qsxjq2pLuTYLjfxHhpLeGAiRemSQm44oWufepaVKiXXRMiSMpEvXBLk5vGzgw5tiB+AkkrcLZEnzdF2DIwPQ2gDhZuKUdQd/CjO8iPU7Fj9yytvU1Vw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=forcepointgov.com; dmarc=pass action=none header.from=forcepointgov.com; dkim=pass header.d=forcepointgov.com; arc=none Received: from SN1P110MB0110.NAMP110.PROD.OUTLOOK.COM (23.103.22.85) by SN1P110MB0256.NAMP110.PROD.OUTLOOK.COM (23.103.30.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.21; Mon, 9 Aug 2021 13:01:02 +0000 Received: from SN1P110MB0110.NAMP110.PROD.OUTLOOK.COM ([23.103.22.85]) by SN1P110MB0110.NAMP110.PROD.OUTLOOK.COM ([23.103.22.85]) with mapi id 15.20.4394.022; Mon, 9 Aug 2021 13:01:02 +0000 From: "Scott, Mark" To: "ipsec@ietf.org" Thread-Topic: Adoption of draft-ietf-ipsecme-labeled-ipsec Thread-Index: AQHXire9Nuq/5FfZAkWWoCgnoimjYqtrJ2ZZ Date: Mon, 9 Aug 2021 13:01:02 +0000 Message-ID: References: In-Reply-To: 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=forcepointgov.com; x-originating-ip: [98.228.60.47] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d40062e9-707f-42bc-862e-08d95b35bdde x-ms-traffictypediagnostic: SN1P110MB0256: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wT+I+59cHXoLQfCyOX5fm8FCAH9eky2FDE/EaUDBMsziVMSDVaUPiFNKuClj/e7RANs8Ej1VFLvRPgJwj+zzND1TZ7wNTYhZAZgpq2Jqy4Brut+pBvRZMvuIwOofQfZrsZK+BAgq7nPXwUhyVPuOYD/LfhHfjgnK6iyvn2zcbiHnKSaNlP5x3bePMYDBX6uDx5L4tIGLH4DMZgT6IwMF9/PdDqq7uSjWt7ogqzI8ftZTYN0uG6ZBYGppX+rboRZWd2Ms2wvFiEU4zrZ/7YA7c03jDmZT8ph1TLDQnfZCpsX3jy7ecsS0r3DW2yB4zaEs25CFMz7tJJgDeEd4H5LKiuwB3/6NUY9XpLWS5KCvS9nqTE3/bIsIjPcUbHitCnqgCuoevEb/pExO5l/plqXiwOMtz7cbn0KzWKSY2t4W7ggl/zLiWoE4qZNwBAClUZ1l/r1qNbQi4KGDBEO9GCw1PXo7F7mdASZy3j7/x6Qe0q7FdCTKgR90Fm/fcPvW6I2N6hYpbAZl8Lab3T1u0FOV4x+kiRNV+5DRty7lcHRYFdNVuBVeGZfajDc5jU1NrBJH4KPAYIjiTcXg8w4NxqyoCfOSlSIvSV8Dxp6rYo+nCFU3pucEbg4b9tancZH/+/zSX63LlOgxfPk8seSZpCjF3yn9ijQoXL0ZeyEXnagdLIbeiZmgjkEIkXNpPcfTQUVKkz2Y7GRqRyYE4dItIeU94w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN1P110MB0110.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(346002)(366004)(136003)(376002)(396003)(39840400004)(83380400001)(52536014)(316002)(66574015)(38070700005)(55016002)(9686003)(76116006)(6916009)(66946007)(66476007)(86362001)(66556008)(64756008)(66446008)(38100700002)(956004)(33656002)(478600001)(6506007)(186003)(4744005)(26005)(122000001)(8676002)(2906002)(8936002)(5660300002)(966005)(71200400001)(7696005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: 3CQCY+UCTZZejeriOq9tWYzAOcmSAX7CPEulV8gD/X7ux9yJ8bDtq1Kls1T6k4XcuRYY0RHAm3USKdCwxmbVJQUq5OA1p9HxTsLlkWuWgPcM3eQQMpjtVRTGq2FxkkNufzal7zC+p1ngrk+03fTeNlVmwmg+IHQeQECjjNLVvtxCiAF0Br0k9Wazj7C6DfpDSEaelXle8LY/4ocUxIp2LS2Ipkn9y/yYsxnFjIWwVXuNUCbszF//E7ieETqtpctYd94yGPdQ5Pm94zzleD0C9I3VXD4RbOTnPhiZxlXWy+i9SUZxIMA0GB75HCu7A3eUDSh615vYQiNygouu2GuM7x4A7818r/Tu1DXyBp3iKfngvzxFGi5w3TkE8CbSabjqiuvpmBPY7NoB8x6mnkNvJz8q/oHjRmZ11OPmiyzo1F+LH3uL7SAfPiBmGCNw3lythLxeovB6LjmF+U2+IZSWblkxC7y8ik6pJRs8ACl6BW57SbAysOcUoT6YechUyW7SSHebRyygqBzIopKlu/Ur7uqoxTA2qSvucFJZuKmiGpYBh4/+qO0QHiaWsourgO/ruDpiLNm5bMYUIKYzyV3sWqqKJ7q+U7oW+8XNlsdbsAUR/LVUoGP1RkIZZxyr2Sani8O2/xYWS3r6e5UsnBfCBawtxbCJe797ea3hGAAKbPMccxK8XH3yOFjpDP6IDFaVVqEVFcD7r6VWYMioKSVFAA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN1P110MB0110.NAMP110.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: d40062e9-707f-42bc-862e-08d95b35bdde X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Aug 2021 13:01:02.4958 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c1def8d1-d468-417f-bc2c-0c2734eaec23 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1P110MB0256 Archived-At: Subject: [IPsec] Adoption 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, 09 Aug 2021 13:01:13 -0000 We have reviewed the current draft for labeled IPsec & would like to see it= s approval move forward. We feel it has broad applicability for various cus= tomer use cases & the ratification of this proposal as a key step for consi= deration of its adoption within one or more of our products. =A0 Thanks =A0 MARK SCOTT Director, Software Engineering Cross Domain Solutions Global Governments & Critical Infrastructure =A0 Forcepoint=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 http://www.forcepoint.com/ Data Protection | Web Security | CASB | NGFW | Advanced Malware Detection= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 Behavioral Analytics | Insider Threat | Email Security | Data Guard | Cross= Domain=A0=A0=A0=A0=A0=A0=A0 =A0 This e-mail and its attachments are for the use of the intended recipient(s= ). =A0Disclosure, reproduction, distribution or other use by any=A0individu= al or entity other than the intended recipient is prohibited. If you are no= t the intended recipient please immediately delete the e-mail and notify th= e sender. =A0 From nobody Mon Aug 9 12:05: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 8FD4B3A1219 for ; Mon, 9 Aug 2021 12:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.064 X-Spam-Level: X-Spam-Status: No, score=-3.064 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, FROM_GOV_DKIM_AU=-0.612, 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 (2048-bit key) header.d=uwe.nsa.gov 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 ylmTTsN12mq5 for ; Mon, 9 Aug 2021 12:05:06 -0700 (PDT) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02on2044.outbound.protection.outlook.com [40.107.89.44]) (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 02C243A11FB for ; Mon, 9 Aug 2021 12:05:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=F55RfHYtHn1dIK2NVgFdgdw2OLOrMMSkkNwLURyh3NmBIj+Tq2CIOmvwJQUto4WBJrObeHfzjIq31gnAPfSgibYdNA2K68bl1qxniyBwfXiZZTQctGqDputrIM81oQCdZZX6OZz/d4lDVWXxLvS9134clZmQsbJZ9nPsSRKPvR/TOOC69R+POcaykkpSe2enFz3LKHL9YTgSAnZkalcW5PBgyiSvnxFqOoQt6Od2JLec7y+LquJVJaUc/+oP8FDyFELsfUbus9wyGSukaKuVrxMVdPloQimFlKJ4Fr59OmE02+sdPYw33qZNPd/6wjjjcLuAVMmy3c+hibIS6+fMEA== 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=OXP/MWzgIuQ4kafqcfyuWgDv2kaZFvOQ702zaiQuf4Q=; b=RWf6EKOwqS91dfTybKJjnvQhY6sqp6gu1D4Xuuw1++pMs0QVzDcC4FexHwyN8N47H3UUvou35ZzQJFMxORbzQGfb0napYjfjEFYTcikN5APnOy0cfDiHg3+sDlKQDj7HJuiUANitjY74MrOG/S2cm9Stvc9mYb5DvTNGx977OWye5bjnKOD9TfikuCJKZMsN1lpREQJ5nBH0BOeePAePV3yIsFiPh6bag7gwid7cr+6SdmrY0LropcdAIMGlkxnBGs1a0G2Vr0wERhvtsZsmDwkM51EknhgA8SafgGidbgqkb1XrZjq2peeZQlgsU9K/7Mup5PkYRmgX5hD4O4RL1Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uwe.nsa.gov; dmarc=pass action=none header.from=uwe.nsa.gov; dkim=pass header.d=uwe.nsa.gov; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uwe.nsa.gov; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OXP/MWzgIuQ4kafqcfyuWgDv2kaZFvOQ702zaiQuf4Q=; b=ZyrlULShNVFS7hPqieOaPp95JvXUl6qwGrcW7Xteh2Aj8o9l8tXTvfWIHgJBHB/MPY6TqNVZhHcSGrfyFPfVtoeNBykQ8e3bGTlwIHsXXJ6AfT+k6zCqeUzmqWtUYLIAEY/lZp6jUqRG4yuFhlNFSDJs57E77JwnsjLyaCU7jH5PACmhR6ZmvZEnnIaeAitEYqqw2eHFWsz6Q/x69xqzDb803irKLvY2JKEH1Gg91xed/iZPL2iO7lg6wDEmOjcM53eRP9eh+n6wMh68/QrsJmNfrLAYEQaePuYJ85KC4RxUfK9p9HxrRIiTAoj4JssWOj+PVLTCLy5sjRsK8uJnPA== Received: from BLAPR09MB7249.namprd09.prod.outlook.com (2603:10b6:208:2ae::14) by MN2PR09MB5179.namprd09.prod.outlook.com (2603:10b6:208:222::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.15; Mon, 9 Aug 2021 19:05:04 +0000 Received: from BLAPR09MB7249.namprd09.prod.outlook.com ([fe80::d9a3:2827:2f8a:134b]) by BLAPR09MB7249.namprd09.prod.outlook.com ([fe80::d9a3:2827:2f8a:134b%7]) with mapi id 15.20.4394.023; Mon, 9 Aug 2021 19:05:04 +0000 From: "rmguthr@uwe.nsa.gov" To: "ipsec@ietf.org" Thread-Topic: [IPsec] WGLC for draft-ietf-ipsecme-ikev2-multiple-ke Thread-Index: AQHXjVBwTGK3yYC6okKYArzyNsgfrA== Date: Mon, 9 Aug 2021 19:05:03 +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=uwe.nsa.gov; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b11a2e4e-108f-41c3-afd1-08d95b689859 x-ms-traffictypediagnostic: MN2PR09MB5179: 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: QRojoIuWJ0930WFV8iczWRRV0GtLAZUG/9sw2/4VhX10WCimdwipuy+W2DmKQ9Ijm04OEtCDX0CRfRbk5/yX0nfbiN43nHP+0x4/F3CheKmxKsaLvoRfLmhzm3ZmunT9rIQymJieXvXqVTeVxVrHfZaGyjBKfLtJif97DzB3vnPaRC5brznV0AiWe9JGFt8h4RC9ZsBpqvu2PFv2OaQGtsqEN/HMhQzkj/oMh4k5YAsLTwErTo3JsEpFLBS3xMTKmUgw1zymW9gKNNBpDLFdCVsIpjqqBLTXR3YBEOXQErmUQIaJu4dm94XKXm5ipWx/+QcfK29c7TlEEwFGH15bvnHrSfV077ZK6KQBBf4IXAVGuVh/lunnOX+wPOPSmFua4dEZOAuYjKiwciRFp52YlKBPPkGhUePXiKLVcLFlwuWeA9X0n6gcZNwC+R3RB6yC0HMqsUR77h8ZN+r4QWSowtQvPoo9lI9sNBbHTepQUNQVVlT7dogQtsZx44xjtEorVfJpKeUaV2EKwH4NovZkw9SY9u0QsVyNM6xD7B8RC3PLJpuXw+33jhdBQPlc5UM93XWRHyHtNJTfFS66R3VOFOhHPXrRpxyzOSXYjxPDmscf5wrX3iPHd1vkYh3hV6kisrOGrRJT6i/IPLGKAOXUqr4+iel3bl3NeyJQuXtRrb+LbDLd7w2q3cvRJA0NKwjIDD/gG055KJ7Ox2zHOyWGLA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BLAPR09MB7249.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(136003)(376002)(396003)(346002)(39850400004)(8936002)(2906002)(66476007)(4744005)(52536014)(33656002)(6506007)(66946007)(64756008)(66556008)(66446008)(76116006)(8676002)(83380400001)(26005)(6916009)(5660300002)(186003)(86362001)(316002)(38100700002)(122000001)(71200400001)(9686003)(478600001)(38070700005)(7696005)(55016002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?84Vc9pyWdGGHPJ9r3c3rR26pU2tucGGC6iiOp2D0KbaKoGsjP/0yOlyH?= =?Windows-1252?Q?ROI1zGBJZjBmXZtao2d0YyGeaKqfahGepcHcRU/VLGpCm3MC13nxw57U?= =?Windows-1252?Q?Py5S90ejlRTPWG/LfJ6UEaFqlU8Ww+k0hOQ/NtYszwZVz6SrwWZbxZkC?= =?Windows-1252?Q?BFGTDddD3gRdgMrfe+6X7qZ7F1m9l7Ba8xK119j9uo7zSYNfE9k99ET7?= =?Windows-1252?Q?4lyLaDEQdrRPIvUcqSM+/d63BQpYjip9XaQ7pxuifqL56NURBdzE54B0?= =?Windows-1252?Q?SASlDnqJqxAd+L3TO50gKiGGEPYttEGRUGqfp3IaZQz1xOQpWQn3uKel?= =?Windows-1252?Q?x3rWnxJ66JCGIj7DIhdU1svatEC1i4tp6CyX0W8VOe90NGmf3KgFhIFK?= =?Windows-1252?Q?Rj+xjDZAXVyBW3m5c5wYWuBQT9D+FhCaM6YDmW2LEk2Bpu3L0Q8vp5ly?= =?Windows-1252?Q?AdCPXJjyVppBFG1aT4V0CtwLB7ifV8XEMDYwYoMzjOkUPlLDKkh9nBwg?= =?Windows-1252?Q?1NcVOZ7sqzlP+8vU55csKHinXSzdvq4lJiiqq6byp0e0i/v56C2Ma983?= =?Windows-1252?Q?O6KLjXEpQehQxD/7WBN1vEWaIVdEPGnjBTjkb2f2r4BvtUl1Wgy3pxWS?= =?Windows-1252?Q?ZuXNbMytTCDX8f3wWzsMnpmnvdl/xBhB7ngIKx58BsEdsGX99AZJi4ok?= =?Windows-1252?Q?aGk/1moT2VtuHEoFcxNbCCIKj0L6g3wuUNeTPvNz7DPgBkkmHBoiDx7B?= =?Windows-1252?Q?Jtw1fBXxW08HroJZpUO4P8My2CiVITCibK9JKDhTcgL2+Wr9ZJrKu1bR?= =?Windows-1252?Q?d3zo262mghpGoME1TGNvit/ivA8w9OdZasrxNxtZtjnscQOsb6xlCUAn?= =?Windows-1252?Q?rc0UtxERNX7l268wKvUOKbRSAqyrG2sW6S2kZf+0tFDm0DeoBtCjLXbN?= =?Windows-1252?Q?yXzCUBxjTvH2x/cqu4IuLdJ3cnuqrlNfyotcCoHYK8/DAh3zk7PuoLHQ?= =?Windows-1252?Q?lMEZx8gAXt6gh0Fae3olr40BROLS8myXTPlNDBtzvGRltSrhyFvSCG/Y?= =?Windows-1252?Q?aRWZbRj2W9+3fn766OnqR00bpHmZM3ZP4+7UaoKAHictHW4IZ5fLcUW3?= =?Windows-1252?Q?5eZYw6MbR07ST8Kf/lENBRsaN8bFHXOJYUi/b2qFPFjdMRDr6my6rNlp?= =?Windows-1252?Q?kVyV9nUK3FFWbs6PM0m/bJ7+XsI/egX2SjinhoyCxeqDWCo+qD1ungTe?= =?Windows-1252?Q?p3gYfCNCdg9GGOcT+U/towxJctn6/3fyhF/JqiWSUzjG+3xZkb9F3c+H?= =?Windows-1252?Q?2WqraWUWIvTFN6tJbwZlSPHTQ3oyGanKOrfJma6TEadfFrpglC+Mnsp6?= =?Windows-1252?Q?oJhsX82XG8twHmZVYAEc9sOgtrowR7uyAAbeD6w3kGWqSuO5NQV1/tzm?= =?Windows-1252?Q?oMa+PJYYPG7l8lReJ86wRg=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BLAPR09MB72493A82600FAA04CC41B844FCF69BLAPR09MB7249namp_" MIME-Version: 1.0 X-OriginatorOrg: uwe.nsa.gov X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BLAPR09MB7249.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b11a2e4e-108f-41c3-afd1-08d95b689859 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Aug 2021 19:05:03.9739 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d61e9a6f-fc16-4f84-8a3e-6eeff33e136b X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR09MB5179 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: Mon, 09 Aug 2021 19:05:12 -0000 --_000_BLAPR09MB72493A82600FAA04CC41B844FCF69BLAPR09MB7249namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Good afternoon, Has there been any thought on whether to include more information on KEMs s= pecifically, with regard to the KeyGen, Encaps, and Decaps algorithms? It i= s my understanding that a public key (pk) will be sent in the KEi payload a= nd that a ciphertext (ct) will be sent in the KEr payload. The hybrid draft= for TLS 1.3 does provide this info and gives a brief explanation of how th= e KEM data maps to TLS, included below: "For the client's share, the "key_exchange" are the "pk" outputs of the cor= responding KEMs' "KeyGen" algorithms, if that algorithm corresponds to a KE= M; or the (EC)DH ephemeral key share, if that algorithm corresponds to an (= EC)DH group. For the server's share, the "key_exchange" values are the "ct= " outputs of the corresponding KEMs' "Encaps" algorithms, if that algorithm= corresponds to a KEM; or the (EC)DH ephemeral key share, if that algorithm= corresponds to an (EC)DH group." Thanks, Rebecca Guthrie NSA=92s Center for Cybersecurity Standards --_000_BLAPR09MB72493A82600FAA04CC41B844FCF69BLAPR09MB7249namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

 

Good afternoon,

 

Has there been any thought on whether to include more= information on KEMs specifically, with regard to the KeyGen, Encaps, and D= ecaps algorithms? It is my understanding that a public key (pk) will be sent in the KEi payload and that a cipherte= xt (ct) will be sent in the KEr payload. The hybrid draft for TLS 1.3 does = provide this info and gives a brief explanation of how the KEM data maps to= TLS, included below:

 

"For the client's share= , the "key_exchange" are the "pk" outputs of the corres= ponding KEMs' "KeyGen" algorithms, if that algorithm corresponds to a KEM; or the (EC)DH ephemeral key share, if that algorithm corresponds= to an (EC)DH group.  For the server's share, the "key_exchange&q= uot; values are the "ct" outputs of the corresponding KEMs' "= ;Encaps" algorithms, if that algorithm corresponds to a KEM; or the (EC)DH ephemeral key share, if that algorithm corresponds to an (EC)DH= group."

 

Thanks,

 

Rebecca Guthrie

NSA=92s Center for Cybersecurity Standards=

--_000_BLAPR09MB72493A82600FAA04CC41B844FCF69BLAPR09MB7249namp_-- From nobody Mon Aug 9 12:42:30 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 D41F43A1584 for ; Mon, 9 Aug 2021 12:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, 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 9cPLo-9edIpQ for ; Mon, 9 Aug 2021 12:42:22 -0700 (PDT) Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (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 C4A3E3A1435 for ; Mon, 9 Aug 2021 12:42:10 -0700 (PDT) Received: by mail-qv1-xf29.google.com with SMTP id db14so9596617qvb.10 for ; Mon, 09 Aug 2021 12:42:10 -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=O7BpTIcKqCiWf7mYtu+zWgy66PYjlgjoldnWn9kP69g=; b=YpFz7dNwLAV8Mov8wWj05qfjfnjqOfVvkjxDr/6YAJJiGqKx/ChBp6Xozo3ngHkS8/ Ia4z8ON+eg2thzvCCNAv6HS5dlkiW+eCOEVrtaK5a+lh0VqwO4hNkDIPKqyI5oJOTZ0e AskcycZ3oXImQhFD7hrD/1SBwEXAGWxTH5jWcgnRLQDGaJg/N9qH+hjwa9qo6euLA8Sp 6JN8tmPUCce/1YqvIP1F4znTm/YVkyBKodpBYwGwTXN+v18B58WWmj+YolzGeQU9F2Jv jOj1COFJs2J0cPTjZT2gjFuP6FdiNZHyigfVlf9+b2ydUFAgwMPOkLQlgbFSby4uNw8i ulJA== 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=O7BpTIcKqCiWf7mYtu+zWgy66PYjlgjoldnWn9kP69g=; b=cfe1NqQYO3d35Eit8SIHi5dLUNv7Rahmb9z39rewCqqJwM3LGdM0fw1OKPx0tvGNim MVZtIHTLHxWdnTK63Vqmrl5tkjXit0VM7kj2MTc77oPvptX21P6jPeS7AIRqyF7TEdIm KpenKIWkKQSzSwRwso/9B+joGsbdEGGrI1Z24yr6L/hnuAmLE7u7ByIr0uOeL0uJkVZJ 9bThaQPLSymH+pFiwP1vbOlSKsGiiOVThTZyoKJn2mcHmEle3OLyDqPccu2c0f5G2GGm riA0doDNteYgjuvND5COQwu658P6iIGyOnZpbM7J6nntSrKOH1VYm0cUFvpTzrm5EQtV RdGQ== X-Gm-Message-State: AOAM533q1duOFZk66JpN0ZhNw+Q20Y93NqmzlCRrB/4/OWSJ9l+xeoJk 0Uy/Janyx9YdifDjhS42IrMa6fgbzH36Wk6Dj8S0uFdu0mg= X-Google-Smtp-Source: ABdhPJwbIKKgqik/7RtSx7GZ3qps+Iv3ktGTq1od+hVbWTsh1xcOgMWnDnqfUFEOo2HjMYXCi5Xxe78ad0NHvLCpRvc= X-Received: by 2002:a0c:ead1:: with SMTP id y17mr25615782qvp.12.1628538127983; Mon, 09 Aug 2021 12:42:07 -0700 (PDT) MIME-Version: 1.0 From: Sahana Prasad Date: Mon, 9 Aug 2021 21:41:32 +0200 Message-ID: To: ipsec@ietf.org Content-Type: multipart/alternative; boundary="0000000000009f29e005c9259432" Archived-At: Subject: [IPsec] Status of Labeled IPsec draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2021 19:42:28 -0000 --0000000000009f29e005c9259432 Content-Type: text/plain; charset="UTF-8" Hello everyone, Red Hat has already shipped Labeled IPsec in RHEL 8.4 using libreswan based on the Early Code Point allocation. We would like to see this document [1] proceed to RFC status. Kindly let us know your views on the same. [1] https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-labeled-ipsec-05 Thank you, Regards, Sahana Prasad --0000000000009f29e005c9259432 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,

Red Hat has already shipped Labeled IPsec in RHEL 8.4 using libreswan based on the Early Code Point allocation. We would like to see this=20 document [1] proceed to RFC status.
Kindly let us know=C2=A0your views on the same.

[1] https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-labeled-i= psec-05

Thank you,
Regards,
Sahana Prasad
--0000000000009f29e005c9259432-- From shebburn@redhat.com Mon Aug 9 12:47:59 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 AE1873A1481 for ; Mon, 9 Aug 2021 12:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 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_MSPIKE_H2=-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=redhat.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 CRct8NJbaFvY for ; Mon, 9 Aug 2021 12:47:54 -0700 (PDT) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) (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 35BA83A1482 for ; Mon, 9 Aug 2021 12:47:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1628538473; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=2bWZSbTKxjPin7LuqoPd358kFGi6KdN+1webZw49iHk=; b=ElOGrdafistPfHSuEzYLZpi5qq/vCmmNCm4ECKH0Dmh5JFlKay1GGHyO+HEDc8imwfmYYG rgoBMn7vS+L5/brIoT92Rwbot0+Jw3DKKhPX8z15gOGtzmGbT+qCC59iu/wsuWNaCVmGds h6WcTAYyZeTGIa+IK4Z4bl0VCIx69vI= Received: from mail-lj1-f200.google.com (mail-lj1-f200.google.com [209.85.208.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-585-HGLTKFtYNqqmbBWhDMbKvg-1; Mon, 09 Aug 2021 15:47:50 -0400 X-MC-Unique: HGLTKFtYNqqmbBWhDMbKvg-1 Received: by mail-lj1-f200.google.com with SMTP id m4-20020a2ea8840000b029018ba0baeb6eso3993342ljq.5 for ; Mon, 09 Aug 2021 12:47:49 -0700 (PDT) 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=2bWZSbTKxjPin7LuqoPd358kFGi6KdN+1webZw49iHk=; b=kwWrmOQBfSowzhtB6k33b8b/wUnH3LtYLVL5U8Ua0FDUVasO1usZqsnkZFQXnu2WPz YECCAKA/k6ZxWZ+99/qPdS22649NbpEnybL5CjF1C4Xo75S3zqzxqdY86nSuG0C6e/oH zg7vVJThK5Gpo0amb3JM/gbG1MQykSCzc1jAOwcXTzxlC9b0XPJRaliEtIVJ8Xc3r9s4 P/0CZT7zOlKpdTfb3BV5VxPam+svtFGUWbaaKaJ9HZW2XksUynBJLSLl9tfAO1gCGSiC OLict6o2VR+nTFqcPsiQsq5NmgygSJXUW2C2HcolpwaiqFQiZgrkrJyEyL8tQ08WJTEb 4nOg== X-Gm-Message-State: AOAM532eE7Z86V5PA70ci294QF2J0/MrA2656MRnPSzW7p4K2GzYvwNc V+x8JJLMcukzk0fK0HDVroH3q2x6EEJ1ELFxVxpYJWj8nyVWW4gHB6AZadTH5Vp0/35DV02N5Bt 0xji/gXzPpqclWvYIOi7yew== X-Received: by 2002:a19:2d52:: with SMTP id t18mr18198391lft.575.1628538467981; Mon, 09 Aug 2021 12:47:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxQIRYboeLvayYMFjH4etefNe0ItHtHw1+h2bgcF1PfV3RNOHY0N0aSD2b2nCVQTic2D1hrnViB7CbAItbtCWo= X-Received: by 2002:a19:2d52:: with SMTP id t18mr18198380lft.575.1628538467788; Mon, 09 Aug 2021 12:47:47 -0700 (PDT) MIME-Version: 1.0 From: Sahana Prasad Date: Mon, 9 Aug 2021 21:47:12 +0200 Message-ID: To: ipsec@ietf.org Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=shebburn@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="000000000000e03bb605c925a8dd" Archived-At: Subject: [IPsec] Status of Labeled IPsec draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2021 05:40:41 -0000 --000000000000e03bb605c925a8dd Content-Type: text/plain; charset="UTF-8" (resending from my office email) Hello everyone, Red Hat has already shipped Labeled IPsec in RHEL 8.4 using libreswan based on the Early Code Point allocation. We would like to see this document [1] proceed to RFC status. Kindly let us know your views on the same. [1] https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-labeled-ipsec-05 Thank you, Regards, Sahana Prasad --000000000000e03bb605c925a8dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(resending from my office email)

=
Hello everyone,

Red Hat has already shipped Labeled IPsec in RHEL 8.4 using libreswan based on the Early Code Point allocation. We would like to see this=20 document [1] proceed to RFC status.
Kindly= let us know=C2=A0your views on the same.


--000000000000e03bb605c925a8dd-- From nobody Tue Aug 10 06:52:46 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 CD2FD3A0B86 for ; Tue, 10 Aug 2021 06:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=post-quantum-com.20150623.gappssmtp.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 tcHN0OXzHp2d for ; Tue, 10 Aug 2021 06:52:38 -0700 (PDT) Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (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 4B9F03A0B84 for ; Tue, 10 Aug 2021 06:52:38 -0700 (PDT) Received: by mail-yb1-xb32.google.com with SMTP id l3so3877030ybt.7 for ; Tue, 10 Aug 2021 06:52:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=post-quantum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XS2B4Z0uISq4QKdDVQ8UHX48BhxmEcR05TrL/reFJkk=; b=Ja7YuXANokIinm0nz2xaHFGB3bkNuq0xYYFXubMnNb/w15UHAM1vLx1dP0c7bPNBqk MsVxlKI1+bi79uRcHQ5eO3PvW1wHDxaEDyYD+nBL/2gDwfqbU8VtoVWDd84CtRzZ8vDH 54EdoZZ8nasGuLFb26bhJKFNtpo22h7b4etzBOXcaztGXX6P7dCbKsVqvMClfuKxoYg3 SdEOetIZEDXinIaEYIRrDVoylS2FrGurbtJad7Qc5NZhbEGADLzLAYAX2PUSyFicnXMD IzOSnG6PX3Q1odH1Ud3UCO2HJeRwQsWJoUF475piLZ1IJtBGzKBivLpoBbhOhkY+z5eF plrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XS2B4Z0uISq4QKdDVQ8UHX48BhxmEcR05TrL/reFJkk=; b=mUBrbmkA52JQq5n0V8WHWmIxLTfehOgUH5a9xpn5zJr+m567X/Pvyba/wJTKV79Hjz dNegWyYF8poPa1KKg89vKrmeEkiosr12K1PjFRU871H3wKTrq3rhlCWkB97bxRoLVk2K r5eQ+qZ+QdiVmj+4RqcDXmgEa/w2h/G6iNjQDHMbhN8rL/Z7QFS/OtjDKMK8JaZMcCqY BZcrFVsSwqZVK+c3eNppkPdYWQfBmNj/QEQQ4Pzp5ejycv2KoyWAvyZezN7M7e9uYDsW tNguneUgi+f4bD4FBfuFtS/ZICLluw0uJu5mmZ8dUU13yfPsTYSyKeiJy0tlGm+LT5GU tYSg== X-Gm-Message-State: AOAM530NHeLOFnZBUeDTnxotVqK7scRFF0b27DRAQ0ILeE0H42KiaMSe Lo1f7qRrISa9aWAloyji84p/kmb2XcgMGqfp56ikqDcRljXBJNsw3EfHeJy4S6ChM7RqZ6Kpocg 5XVg9X8xVM0MHaqkHIVyND49dgg== X-Google-Smtp-Source: ABdhPJz+wpQzzhQGisBZEF2ysKEOAEE79HKBFhuiFh7tgINRw4/tppM9dH9Jue5I1UaU2Uw4tk91Q56Ca1rrCHYGKaE= X-Received: by 2002:a25:814f:: with SMTP id j15mr37721946ybm.358.1628603555560; Tue, 10 Aug 2021 06:52:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: CJ Tjhai Date: Tue, 10 Aug 2021 14:52:24 +0100 Message-ID: To: "rmguthr@uwe.nsa.gov" Cc: "ipsec@ietf.org" Content-Type: multipart/alternative; boundary="00000000000068d4f705c934d095" 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, 10 Aug 2021 13:52:45 -0000 --00000000000068d4f705c934d095 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Rebecca, The draft document aims to be as generic as possible, treating the KE payload as opaque. It should cater for cases such as: - multiple key exchanges involving more than one (EC)DH groups (perhaps due to policy requirements); - combinations of (EC)DH and KEM; - KEM only, either single or multiple key-exchanges; - or perhaps future post-quantum key-exchange that is analogous to DH key-exchange; I expect that, as in the case of RFC8031 describing how to use Curve25519 and Curve448 on IKEv2, there will be specific documents on how to use a post-quantum key-establishment algorithm that follows this draft. So if the algorithm is a KEM, I expect the detail of the KEi and KEr to be described there. Best regards, CJ On Mon, 9 Aug 2021 at 20:05, rmguthr@uwe.nsa.gov wrote: > > > Good afternoon, > > > > Has there been any thought on whether to include more information on KEMs > specifically, with regard to the KeyGen, Encaps, and Decaps algorithms? I= t > is my understanding that a public key (pk) will be sent in the KEi payloa= d > and that a ciphertext (ct) will be sent in the KEr payload. The hybrid > draft for TLS 1.3 does provide this info and gives a brief explanation of > how the KEM data maps to TLS, included below: > > > > "For the client's share, the "key_exchange" are the "pk" outputs of the > corresponding KEMs' "KeyGen" algorithms, if that algorithm corresponds to= a > KEM; or the (EC)DH ephemeral key share, if that algorithm corresponds to = an > (EC)DH group. For the server's share, the "key_exchange" values are the > "ct" outputs of the corresponding KEMs' "Encaps" algorithms, if that > algorithm corresponds to a KEM; or the (EC)DH ephemeral key share, if tha= t > algorithm corresponds to an (EC)DH group." > > > > Thanks, > > > > Rebecca Guthrie > > NSA=E2=80=99s Center for Cybersecurity Standards > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --=20 PQ Solutions Limited (trading as =E2=80=98Post-Quantum=E2=80=99) is a priva= te limited=20 company incorporated in England and Wales with=C2=A0registered number 06808= 505. =C2=A0 This email is meant only for the intended recipient. If you have received= =20 this email in error, any review, use, dissemination,=C2=A0distribution, or= =20 copying of this email is strictly prohibited. Please notify us immediately= =20 of the error by return email and please=C2=A0delete this message from your= =20 system. Thank you in advance for your cooperation. For more information=20 about Post-Quantum, please visit www.post-quantum.com=20 . In the course of our business relationship,=20 we may collect, store and transfer information about you. Please see our=20 privacy=C2=A0notice at www.post-quantum.com/privacy-notice=20 to learn about how we use this= =20 information. --00000000000068d4f705c934d095 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Rebecca,

The draft document aims to = be as generic as possible, treating the KE payload as opaque. It should cat= er for cases such as:
- multiple key exchanges involving more tha= n one (EC)DH groups (perhaps due to policy requirements);
- combi= nations of (EC)DH and KEM;
- KEM only, either single or multiple = key-exchanges;
- or perhaps future post-quantum key-exchange that= is analogous to DH key-exchange;

I expect that, a= s in the case of RFC8031 describing how to use=C2=A0Curve25519 and Curve448= on IKEv2, there will be specific documents on how to use a post-quantum ke= y-establishment algorithm that follows this draft. So if the algorithm is a= KEM, I expect the detail of the KEi and KEr to be described there.

Best regards,
CJ

=C2= =A0

On Mon, 9 Aug 2021 at 20:05, rmguthr@uwe.nsa.gov <rmguthr=3D40uwe.nsa.gov@dmarc.ietf.org> wrote:

=C2=A0

Good afternoon,=

=C2=A0

Has there been any thought on= whether to include more information on KEMs specifically, with regard to t= he KeyGen, Encaps, and Decaps algorithms? It is my understanding that a public key (pk) will be sent in the KEi payload and that a cipherte= xt (ct) will be sent in the KEr payload. The hybrid draft for TLS 1.3 does = provide this info and gives a brief explanation of how the KEM data maps to= TLS, included below:

=C2=A0

&= quot;For the client's share, the "key_exchange" are the "= ;pk" outputs of the corresponding KEMs' "KeyGen" algorit= hms, if that algorithm corresponds to a KEM; or the (EC)DH ephemeral key share, if that algorithm corresponds= to an (EC)DH group.=C2=A0 For the server's share, the "key_exchan= ge" values are the "ct" outputs of the corresponding KEMs= 9; "Encaps" algorithms, if that algorithm corresponds to a KEM; o= r the (EC)DH ephemeral key share, if that algorithm corresponds to an (EC)DH= group."

=C2=A0

Thanks,<= /span>

=C2=A0

Rebecca Guthrie=

NSA=E2=80=99s Center for Cybe= rsecurity Standards

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

<= /div>
PQ Solutions Limited (trading as =E2=80=98Post-Quantum=E2=80=99) = is a private limited company incorporated in England and Wales with=C2=A0registered number 06808505.
=C2=A0
This= email is meant only for the intended recipient. If you have received this = email in error, any review, use, dissemination,=C2=A0distribution,= or copying of this email is strictly prohibited. Please notify us immediat= ely of the error by return email and please=C2=A0delete this message from= your system. Thank you in advance for your cooperation.
<= span style=3D"font-size:13px;font-family:Arial,Helvetica,sans-serif">
For more information about Post-Quantum, please visit www.post-quantum.com.
--00000000000068d4f705c934d095-- From nobody Sat Aug 14 17:29: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 293363A19C1; Sat, 14 Aug 2021 17:29:15 -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 M6z8K_fbE0hj; Sat, 14 Aug 2021 17:29:10 -0700 (PDT) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (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 F3EA03A19BE; Sat, 14 Aug 2021 17:29:09 -0700 (PDT) Received: by mail-oi1-x22e.google.com with SMTP id t35so21592666oiw.9; Sat, 14 Aug 2021 17:29:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nPWqMcif2zgtKRTkJKJ7GwBGEUQnqRiMzTe+s6XY16E=; b=besa/6dvLLlXVEAvjU4xqFOa94NeE7pi6l/riUJX73ZpyOT3j38JMv6f3KSaYSjJyZ GzCeC/H/HITvIZy0Bd21gepQErqlw3mTyxQzjL9WxIusUsDAhUnJ9r2ookL75QLDl8aL HwH+PrIGGlAN9M9rsI2a7eYJlzUUf+ccQx/53e7HoDNsacbrEU3CEbIP7v3tmzBLkFgd X/a292HuBEvpCehthpvtJrhxRsgl6NW2NIXGmR6RbwW3qN0o6kilW71+XoBI8AxMlaaQ 7fjvgBJAPu8oVU3tuTCqDyX8TC3GTF7iLQAVfvGPyoL4W3CWmnLg4BTuYh4H4sskCbjD ooCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nPWqMcif2zgtKRTkJKJ7GwBGEUQnqRiMzTe+s6XY16E=; b=Bid6tmj8pJ6zjY4Iw+wjwfmhzHT6/hdlMFuxv801/xa5Kkv/FdSumQqnxfNT2xSpa8 398qh+PrOw/tY8S7m9CNAgMfuRiBsOwKl8Edm+Jpb3J4viBUFke5ZqTdevFkwh0sRcWM D0kfS6qzND/dOcUQhxIsH/Vwg91n2X6mM1VZDSb3nUuykTnoO67CjuNurCcx0KBmfxEl pGv1MEij7M8bUX8/AsFZIWWm3QhY1mtBG+uzbSBnUXAbkT+6H9qNmrghnYwEQcfgCgaS 9M3461jVoc5D2HnkobGICiKAU6QB7qzHphlmFFXZ0a4vZLsUy//NfLlerJ1WzRbhGNja a1Sg== X-Gm-Message-State: AOAM531ugNRbyJr3bFMR66o6FkAfQN31O319Hqhjq88AujSq+dDrFnWh OiamIXXZxD3HAWckXE3oAzQj37bIHeER9+jLVXSGqmX3 X-Google-Smtp-Source: ABdhPJwamcP2oM9ApxFodAj1OAQDEb0lWJHvqqR3X5jie1E/gVJU/rJik/oK7DQIeFtoCAfYQw3enaTXVtyvdTFqvZg= X-Received: by 2002:a05:6808:90:: with SMTP id s16mr5856371oic.100.1628987347626; Sat, 14 Aug 2021 17:29:07 -0700 (PDT) MIME-Version: 1.0 References: <162880504674.13994.12206662169258923789@ietfa.amsl.com> In-Reply-To: <162880504674.13994.12206662169258923789@ietfa.amsl.com> From: Erik Kline Date: Sat, 14 Aug 2021 17:28:57 -0700 Message-ID: To: last-call@ietf.org, ipsec@ietf.org Cc: IETF-Announce , draft-ietf-lwig-minimal-esp@ietf.org, lwig-chairs@ietf.org, lwip@ietf.org, Mohit Sethi M Content-Type: multipart/alternative; boundary="00000000000032ed6d05c98e2cb2" Archived-At: Subject: Re: [IPsec] Last Call: (Minimal ESP) to Informational RFC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2021 00:29:15 -0000 --00000000000032ed6d05c98e2cb2 Content-Type: text/plain; charset="UTF-8" [+ipsec] On Thu, Aug 12, 2021 at 2:50 PM The IESG wrote: > > The IESG has received a request from the Light-Weight Implementation > Guidance > WG (lwig) to consider the following document: - 'Minimal ESP' > as Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > last-call@ietf.org mailing lists by 2021-08-26. Exceptionally, comments > may > be sent to iesg@ietf.org instead. In either case, please retain the > beginning > of the Subject line to allow automated sorting. > > Abstract > > > This document describes a minimal implementation of the IP > Encapsulation Security Payload (ESP) defined in RFC 4303. Its > purpose is to enable implementation of ESP with a minimal set of > options to remain compatible with ESP as described in RFC 4303. A > minimal version of ESP is not intended to become a replacement of the > RFC 4303 ESP. Instead, a minimal implementation is expected to be > optimized for constrained environment while remaining interoperable > with implementations of RFC 4303 ESP. Some constraints include > limiting the number of flash writes, handling frequent wakeup / sleep > states, limiting wakeup time, or reducing the use of random > generation. > > This document does not update or modify RFC 4303, but provides a > compact description of how to implement the minimal version of the > protocol. RFC 4303 remains the authoritative description. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-lwig-minimal-esp/ > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > --00000000000032ed6d05c98e2cb2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[+ipsec]

On Thu, Aug 12, 2021 at 2:50 PM The IESG <iesg-secretary@ietf.org> wrote= :

The IESG has received a request from the Light-Weight Implementation Guidan= ce
WG (lwig) to consider the following document: - 'Minimal ESP'
=C2=A0 <draft-ietf-lwig-minimal-esp-06.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final=
comments on this action. Please send substantive comments to the
last-call@ietf.org<= /a> mailing lists by 2021-08-26. Exceptionally, comments may
be sent to iesg@ietf.org= instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


=C2=A0 =C2=A0This document describes a minimal implementation of the IP
=C2=A0 =C2=A0Encapsulation Security Payload (ESP) defined in RFC 4303.=C2= =A0 Its
=C2=A0 =C2=A0purpose is to enable implementation of ESP with a minimal set = of
=C2=A0 =C2=A0options to remain compatible with ESP as described in RFC 4303= .=C2=A0 A
=C2=A0 =C2=A0minimal version of ESP is not intended to become a replacement= of the
=C2=A0 =C2=A0RFC 4303 ESP.=C2=A0 Instead, a minimal implementation is expec= ted to be
=C2=A0 =C2=A0optimized for constrained environment while remaining interope= rable
=C2=A0 =C2=A0with implementations of RFC 4303 ESP.=C2=A0 Some constraints i= nclude
=C2=A0 =C2=A0limiting the number of flash writes, handling frequent wakeup = / sleep
=C2=A0 =C2=A0states, limiting wakeup time, or reducing the use of random =C2=A0 =C2=A0generation.

=C2=A0 =C2=A0This document does not update or modify RFC 4303, but provides= a
=C2=A0 =C2=A0compact description of how to implement the minimal version of= the
=C2=A0 =C2=A0protocol.=C2=A0 RFC 4303 remains the authoritative description= .




The file can be obtained via
https://datatracker.ietf.org/doc/draft-= ietf-lwig-minimal-esp/



No IPR declarations have been submitted directly on this I-D.





--00000000000032ed6d05c98e2cb2-- From nobody Mon Aug 16 00:59:33 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40183A0914 for ; Mon, 16 Aug 2021 00:59:31 -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 rkvnfFGVBSxj for ; Mon, 16 Aug 2021 00:59:26 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC813A0913 for ; Mon, 16 Aug 2021 00:59:26 -0700 (PDT) Received: from smtpclient.apple (047-026-251-217.res.spectrum.com [47.26.251.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 07FD880EA1; Mon, 16 Aug 2021 07:59:24 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Christian Hopps In-Reply-To: Date: Mon, 16 Aug 2021 03:59:24 -0400 Cc: ipsec@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <41C188CD-9B34-4FD9-A9B9-632C335253A4@chopps.org> References: To: Christian Hopps X-Mailer: Apple Mail (2.3654.100.0.2.22) 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, 16 Aug 2021 07:59:32 -0000 Hi, During the last IETF meeting it was agreed that we would move quickly to = resolve any issues that Tero had left, and get this document submitted = to the IESG. So asking again if the new version (published prior to the = meeting) satisfied the issues so we can move forward? Thanks, Chris. > On Jul 5, 2021, at 3:48 AM, Christian Hopps wrote: >=20 >=20 > Christian Hopps writes: >=20 >> Hi Tero, >>=20 >> 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. >=20 > 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. >=20 > As this document achieved WGLC consensus over 3 months ago, I would = request that the process please continue forward. >=20 > Thanks, > Chris. > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Aug 16 10:45:59 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 E3F453A18A0 for ; Mon, 16 Aug 2021 10:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.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 X4hPOGxQzbPc for ; Mon, 16 Aug 2021 10:45:53 -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 3A43E3A1899 for ; Mon, 16 Aug 2021 10:45:53 -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 meesny.iki.fi (Postfix) with ESMTPSA id B4AEE20050; Mon, 16 Aug 2021 20:45:49 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1629135949; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=B87G7WOFKByCFf+LRbuyCW1hWt0/Y+s+dxMJPz98GRw=; b=NLhc+Wg1saBddAGNwosNIGEFjFGafuEL5VirMtVuGN0ZlCaNPpTL2kaBBiL8NBjC08ln7h KHSHmu6N8929K3/tNWUzOal4DDPhwAzwg6eMxeZsUAI7mu5Vo5Zpvs5bCkxWY/YOou16TF IeZ8EnfaNnQ5oYsiTpNfeIXKn5I17kQ= Received: by fireball.acr.fi (Postfix, from userid 15204) id 301A225C0F06; Mon, 16 Aug 2021 20:45:49 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24858.42061.118149.546106@fireball.acr.fi> Date: Mon, 16 Aug 2021 20:45:49 +0300 From: Tero Kivinen To: Christian Hopps Cc: ipsec@ietf.org In-Reply-To: <41C188CD-9B34-4FD9-A9B9-632C335253A4@chopps.org> References: <41C188CD-9B34-4FD9-A9B9-632C335253A4@chopps.org> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 19 min X-Total-Time: 22 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1629135949; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=B87G7WOFKByCFf+LRbuyCW1hWt0/Y+s+dxMJPz98GRw=; b=ia3Wg3matD2G99PjozbPvAvIF3JcCmHD8FarHu5VzE41NtxB4n4Kl/51ZXmcq2OOktueVN 4qk6j8dBpI+24MA/D6rc49EESuAFn7rwXhT0TgO6pEMx2bvz6Ws65UhEywdZ+lsN32p0kZ u9fb2LVFaK2scQqGgrUihXBOKlmFaz8= ARC-Seal: i=1; s=meesny; d=iki.fi; t=1629135949; a=rsa-sha256; cv=none; b=F+wBPZzl5ure6z0PThrdy4FxtEKUv+VSPSccuTLH1TJHH2ZErIXxM240LxMsuz6l6QJGmS I3xT3W8YuDwO4dbJiZeY/c1xOocDT1Xk9ryLjxtEWqsxQRjqaZzIWBRACpzT3Xijy+SUJm sPl7ZJ6xDGbKytcQFvs1cfSknZwlb2Y= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi 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, 16 Aug 2021 17:45:58 -0000 Christian Hopps writes: > During the last IETF meeting it was agreed that we would move > quickly to resolve any issues that Tero had left, and get this > document submitted to the IESG. So asking again if the new version > (published prior to the meeting) satisfied the issues so we can move > forward? No. You did not address any of my concerns there. I am not even sure if you read my email where I presented my concerns, as I have not seen any other comment on them than except complaining that this is not meant for low bandwith situations and my examples using them were not interesting. Last week when I was reading your draft I got really disappointed when I noticed that section 2.5 was completely unchanged, when you did say you had addressed my comments. I got so annoyed, that I decided to wait before sending my reply as I know how hard it is write constructive text when you are annoyed. You seemed way too much concentrating on my example using slow link speed, and not to the fact that section 2.5 (implictly) requires you to wait for packets to drop out of reorder window before they can be processed at all: Essentially the section 2.5 says that you first reorder, and wait for all missing packets and finally processes the in-order payload streams to extract the inner-packets. >From my original email: ---------------------------------------------------------------------- If we do allow forwarding complete packets in out of order manner, what should we do in case packet O<24> is lost? Should we allow forwarding I<7> immediately when we received O<25>, or do we need to wait 4 more seconds to see whether O<24> ever arrives before we deem both I<5> and I<6> as lost (because fragments of them are lost), and send I<4> and I<7> forward? If we do allow processing of outer packets in that kind of out of order manner, then that will of course mean that there might be reordering happening because of this, and this most likely needs to be mentioned in the draft too. On the other hand I would assume that in normal cases lost packets are much more common than reordered packets, but there are most likely cases where there is lots of reordering, but not that much of lost packets. ---------------------------------------------------------------------- I.e., I want section 2.5 to explictly mention how to do processing of the AGGFRAG_PAYLOADS, i.e., is receiver allowed to forward parts of the inner packets out even when previous packets are missing, and they of course need to wait until all piecess of large fragmented packets arrive before they can forward it, but can they send packets that were in the first packet which did arrive out immediately when they arrive (I would assume yes), and if some packets are missing in the middle, I would assume that they can extract the inner-packets from later packets too even when there is some packets missing. The last paragraph of 2.5 which says: Finally, the receiver processes the now in-order AGGFRAG_PAYLOAD payload stream to extract the inner-packets (Section 2.2.3, Section 6.1). would indicate that you do require full completele in-order payload stream before you start extracting any inner-packets from the stream, meaning that for every single lost or reordered frame you need to stall until that frame drops out of reordering window to make sure they have in-order payload stream. Only after the packet drops out from the reorder window they can be sure it was lost thus only after that they know they do have in-order stream that do have some gaps in it. So adding text saying "Receiver MAY process any completely received inner-packets immediately they are fully received." would solve a lot of problems, but of course that would contradict the last paragraph which do say we process inner-packets only in order. Also if we do allow processing inner-packets immediately when we have received full packet inside the AGGFRAG_PAYLOAD payload stream this may will cause the reordering which happened in the outer transport to be duplicated for inner-packets too, so we should most likely add note for that. If we do not allow processing inner-packets immediately but must wait until all the packets are received and the missing packet drops out of reorder buffer that will cause us to create extra buffering and extra burstines, so then we should add note about that. -- kivinen@iki.fi From nobody Mon Aug 16 11:04: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 9E41F3A094A for ; Mon, 16 Aug 2021 11:04:01 -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 (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 6katc6kKWvci for ; Mon, 16 Aug 2021 11:03:57 -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 E057E3A0943 for ; Mon, 16 Aug 2021 11:03:56 -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 lahtoruutu.iki.fi (Postfix) with ESMTPSA id E41CD1B00241 for ; Mon, 16 Aug 2021 21:03:45 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1629137026; 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=+XUdTPlXhwOvAOucRl5GrZrwnAYOYwaU6632sl1IlD8=; b=NPzkHimWpuKJ3HExkCrLYxhLJwACy8q/3djyQcmhZCOCG9+LfwPzW1kuXYXeisaEuW50Xd liMdrXhQCs1h09EvVf1Eyn7eNnNnK64Q/fDFIen6B6gQp+SNsL+Oly+EalFgF7IPCBzVSR dOG3tOy+wFStzaMqszV6yoBKUt8rkC4E9WIkwKIcDM9Joq0BiIt2wz9Co7r2XprlEaFtsB JMEeWdLdatM+AD9+6IC9u2o7vUv4OCLlnUD3f5ZPbrsN0S3z9StVUjMESvnZMhebwllveE hadAnt4X/i9EDNta6Sb9fknGrhB570V70/4UUr81/J+ON1Tct0qTUNjMO8YnyQ== Received: by fireball.acr.fi (Postfix, from userid 15204) id 68F9E25C12C9; Mon, 16 Aug 2021 21:03:45 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24858.43137.374251.86485@fireball.acr.fi> Date: Mon, 16 Aug 2021 21:03:45 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 2 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=1629137026; 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=+XUdTPlXhwOvAOucRl5GrZrwnAYOYwaU6632sl1IlD8=; b=vHBO4blyHbmZN97efVhzlid0gbVglTHZag1dYNF4H7g90zfuasY7EycR0C1IEqLNPMktDp iZuULRyUGXoupkBnxrdwiSLIN3Zn8HbS3dRnREFAemoF6e1IhBtR3slPTKVpiTRIxkZruz /l2AnJfqElYOWs1Q6P3/ihquUpq+PEhLhn3yF2E52FI5BssaTIzGSUBOH/Y8gzGa3ypNwu VDr3M3uGoJC/xE2+n0ufz4cdUPrJNdqSnJstZGqUpTougOXfCKPaYe9aAmEUA64ASEQOOH IOuIrwDfiEt1MemOUv/X6/cOnuIj6CuWlO25jVgPVsMVIjNmE3VSu7Z2BxY/jQ== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1629137026; a=rsa-sha256; cv=none; b=WaVwuF49ZB/PT7p4rGuYHan+iGzTFeuker73dLxR+XMjIobsmwwxhqfYUgZkF+mXfP8sw2 d3mz9bxRbvQJJ8/niWeWRxgWgAbe2d0+KqESFdFhYMNpSYMHN2Dh50m+bOWFM0SJm+nArP V9f9O0uQvArtbtASgGShxXoBmsa922YGiwu9shoMVtrFHQJBlTKoWoAQ+DHE9YVp6UqCz3 wiviPvIz2Wr9TNH2Snwjf0E1QNHbbZN0CDyEs0zF3N5j06fhrnq6DmDRlbf0HJUzarQ552 t22BvXSOyxO6q7OgJV66xQASi7roic3EAjn0drFgfMYTCp+KCpdiGKNt+AP6Hg== Archived-At: Subject: [IPsec] WGLC of draft-ietf-ipsecme-ikev1-algo-to-historic X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2021 18:04:02 -0000 I checked the WGLC email threads on the list, and I think consensus was to move this draft forward, but there were some issues pointed up during the last call that still do require to be addressed before that. I moved this draft now to WG Consensus: Waiting for Write-Up: Proposed Standard state with substate of Revised I-D Needed - Issue raised by WGLC. After the authors post a new draft we can request a publication of this draft. -- kivinen@iki.fi From nobody Mon Aug 16 11:06:43 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 78EBC3A0AA7 for ; Mon, 16 Aug 2021 11:06:41 -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 (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 yVorjV4agt0g for ; Mon, 16 Aug 2021 11:06:38 -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 C67FD3A0AA3 for ; Mon, 16 Aug 2021 11:06:38 -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 lahtoruutu.iki.fi (Postfix) with ESMTPSA id 32EE01B002AB for ; Mon, 16 Aug 2021 21:06:36 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1629137196; 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=RHMlhzh+xlIA1qFi57qdLV1w5OMeiljHGimKGtOee2o=; b=g8mYFvlacwOZkD8rSP6ivv/taZCixXn7Lsg4BKDCMGuBSTDSJHWIeTl/DuYqWKkNeHkQSY TaH2KfhkYDTvLt7lqXk+vkbfNu+M52MD2ng/EYOJMuTInlTbl1dC3nOkwF6zYdvUOVPRX4 Vs6kBaPlKHD7uxFYXB7ZOVtUmzLVv1Q99mYs3pyEiF6CQ7CcTO9NQ29zEclZv/gD+gRlH0 7nBerqhb0/VGe+2qZ1DYg/3qKWp/y1D2mJCR5OaxPom37OyPOLR9s5cN5HLcZMKyqSFvKU xGZmfU1azKTIBXwGHY0RIwODCF8g7zqZhnYiV/44+lFJjHtSDwLeGurLZAuZjg== Received: by fireball.acr.fi (Postfix, from userid 15204) id 00CCD25C12C9; Mon, 16 Aug 2021 21:06:36 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24858.43307.978066.371230@fireball.acr.fi> Date: Mon, 16 Aug 2021 21:06:35 +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-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=1629137196; 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=RHMlhzh+xlIA1qFi57qdLV1w5OMeiljHGimKGtOee2o=; b=Kzx4GDmbIsFASDoIWqhNNLkjJxj3YoSiiUXiNZXcUJ311YCv/QEdQoMe+WxDSbrPD0U3E+ OovWnYT81dWFIdCGUjq3G1GCtB4/SBlp4w0tl+csMO4lojVGAK1+uHBRTX8IpGbHR4DiQV ljGy4ftIBRA9pcUrgS+8jGxu2kCDH2cu4wYuqOsdjiHkK9Co1NBYBkuemzPlxYi6azvJTJ 04BYEKrD3X5sronx1vnPv5UOQod7EfKe2DC6gk0VlusiaK+sq8O2LzKIFnqvQUVwZT6XUn E60tqB6LGbY4gcHvVvNV9hd3K0GxUJawanKZX1p9mOwVFrPbT6IpzEmQEiAOaA== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1629137196; a=rsa-sha256; cv=none; b=UODIQ4UneYDIx29bqh/YLKDrygFE0KUsg/GP5rnCw1jo8TtaxoQw9HS5upCEGdwl7aXX4Z kOvkI+lHX7y/wJoKxgc5cmVzR4jn0WDj+Owwc6dCZ6kZgvNM4EJ9iFhH+2nLDnEzDtNarc 2o4cSGuFVZAGAoZE/FTAu0hZEWLnRUWQy/XSqtF5I486hNdWJXmn0kmefMEPizPj/RO3HC R7muJRws5985Ixyw6rf2fruW+4KOSacoK9VBkJjpgCCF2AlagvRwvqgdNW/pcGoVjBv8yF c/CpQvwDETtVslH+OUKlJ7mUlDS1ahXAp46Olf1hu57XM0OS4VcyFfP/IVtatw== Archived-At: Subject: [IPsec] WGLC of draft-ietf-ipsecme-labeled-ipsec done 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, 16 Aug 2021 18:06:42 -0000 There was no issues raised during the WGLC, so this document we will be starting the publication process of this draft soon. -- kivinen@iki.fi From nobody Mon Aug 16 11:16: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 46AEB3A0E95 for ; Mon, 16 Aug 2021 11:16:39 -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 (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 xYRCJQB6Mo_5 for ; Mon, 16 Aug 2021 11:16:37 -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 E2E0A3A0E91 for ; Mon, 16 Aug 2021 11:16:36 -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 lahtoruutu.iki.fi (Postfix) with ESMTPSA id DF3DD1B002AB for ; Mon, 16 Aug 2021 21:16:29 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1629137789; 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: in-reply-to:in-reply-to:references:references; bh=vyUCc/WXmt4M2XNCdmStVWMsf+rvRZ2jUMToih7IbqQ=; b=f6qbBO8oAoeckvkperFVxuEoLOIMXCTUeCpZOMlIoG5KcbF4PUf0oIpLSDSLOcD3hnb94X VHSaBrI/cM8NlYWViIB6wii2CGAP3eozkAe6Lh+oR5YdyUkIVq5G+wnTXB7whtGI/DhmU8 w/o4qW92M2fqX51qzAEmT+LQmCfmChvC+n3jxMPkWhSlaVx10Rr0wqBixhveJ2AAFF3alz 0Nv3FZMgYAYu76TxS64tZ8MgADCFn6q1o+/xNUdIGfJ1OY4UVECQn4Q7TqkB64XYQbnDCQ HgBKJl68PI/eVnY4meKt62Ok0x3O8Z90e3f08nAlz7vxgv9izvOBFQD+PKPdOA== Received: by fireball.acr.fi (Postfix, from userid 15204) id AB7D725C12D8; Mon, 16 Aug 2021 21:16:29 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24858.43901.475270.669783@fireball.acr.fi> Date: Mon, 16 Aug 2021 21:16:29 +0300 From: Tero Kivinen To: ipsec@ietf.org In-Reply-To: <24831.15134.45575.357305@fireball.acr.fi> References: <24831.15134.45575.357305@fireball.acr.fi> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 3 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=1629137789; 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: in-reply-to:in-reply-to:references:references; bh=vyUCc/WXmt4M2XNCdmStVWMsf+rvRZ2jUMToih7IbqQ=; b=G+E0AzaarudiwsHIFs0T4y5IAbbUtvISzuEEsFRL/QVMx0+JZtlM2D2UCeQ8V/tzUpB+6V gKAm4xxu1LmGxbwIz2dKe1viS9Ef0kr+aaI1DN4bTuq4g+WHRVqQbFIdNagoudhRIgB5XE ez6N6xl5vm1yfureMlRE4txpc4GO6Y6skov5O9KICDz7QbiNwPU0PdlCgz3CSTYEAibmCO 4M7lTVmtWkclinxQjR0GH3O5z3WRyjNVTns4uRxXdz3bkkx8m8oziOZOVfrEhA07M+Zo0l ndT/7PL/W8XlV3CgmNTXbpjBvD1btfE7e/5doXE9a+zHIc7Gx73Gvpit7BlkUA== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1629137789; a=rsa-sha256; cv=none; b=PMHgluVtKklIFf2DPXO/kV6tjdzoFOFK7CCvF+HIIZP7HcLUuIscXaP+y3W1mEKxtXn5hb sznsLPwpkbzhS8H8ffosGlGRlweJvAwUTUki5M/Dv28WBCVCknODkZO6IhqvNdYNkv11r5 AGHZK+RBkPE6s1YQS0wHXWLkDWPeWZiHIJAiPKBVk1JkGQ8KH3Q3MLNtdmu50dbuGwutQg IFvsq1emHnz+QI82fcqCJgm2dEytEIPm1xqD4nL1jQ9Ei6gDqyu+cM9MFcfvDp5ZYfXPZB 02Ji92wjsY13YR6zMVhqWxTQ8QJaxnBa3fmCD4Q9bEU0Kci+aOXM1s0m8crQtA== 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, 16 Aug 2021 18:16:39 -0000 Tero Kivinen writes: > 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. The WGLC end time has passed, but there were some issues raised by Paul Wouters during the WGLC, and I would like to get confirmation whether they were resolved or not. My understanding was that most of those issues were just misunderstandings and authors explained them, but I would like to see confirmation from Paul whether he thinks there is something that actually needs to be changed in the draft or not. -- kivinen@iki.fi From nobody Mon Aug 16 11:18:51 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 3F30D3A0FE5 for ; Mon, 16 Aug 2021 11:18:50 -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 (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 mmVDH8XK79qY for ; Mon, 16 Aug 2021 11:18:44 -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 313D53A0FDC for ; Mon, 16 Aug 2021 11:18:44 -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 940C61B002AB for ; Mon, 16 Aug 2021 21:18:41 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1629137921; 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=6dz6qIZxGXGDpJJxPyY9XkYCUxYWmP0Jhz+bokbJTlQ=; b=ZULQNkzmxL/XwT/LQHc+RJ/SxQrNmcid+2GBuCIDsv+KB3xE3apq72Ud8bZwMzmPdX/L/z 2IrT2g8jvVP6eGvDQTHcux4kXaNGL0+IjnhM9YBLZ3uBs0VeMOSZ5RH1TSIr9yfdi0E/I+ oBJm6i4+QkMHn9ONWnxHKSfQ8fU3O6FJAmtEYqGomcso7RWd88TZ6jt7ttvL+jSbiI3M2L ucjWjcSkCyqhmYMxJ39y28JpaRB3gNrey5UapYF2Hm6brj+gPphZ7jkofLkC+VVlW+YKpf IUipaAuSmykDVORWPzOYuZnZAQQIN59W/vsgOypqt7AfhebzGITUlzJdcJm3iQ== Received: by fireball.acr.fi (Postfix, from userid 15204) id 5F13825C12D0; Mon, 16 Aug 2021 21:18:41 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24858.44033.362287.597508@fireball.acr.fi> Date: Mon, 16 Aug 2021 21:18:41 +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-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=1629137921; 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=6dz6qIZxGXGDpJJxPyY9XkYCUxYWmP0Jhz+bokbJTlQ=; b=ckwGgdUCsGXoFjPc6vMf7aH3Opd7FlGcqzBGp3opv/9BTrizORVrvKoE5KQms8vizOQofm eVVv2Lq+4MRcYH9W2l/elKXUtlo1mx8hlyJGUV2pl+PouJdnxOT6YeiLry/P+e2qA2HuFM bc28qKffZS9PlEe0nkJrGq15p5AQu99rhDprQo3OvqEz5F7Sz48+zy82WEHYupzM0gqlqr REZbRfECMFNpekTJApW3wNeBYLTsIOfX95JCOYYIDfAfIveILYohTlcC4xLh0x1thAjtbj xn8NKfDfQnl15xPEbbaqNs0Xk/W8HbFSJlJFWa1nDrhMRX0AlbiKRTcdsn/nUg== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1629137921; a=rsa-sha256; cv=none; b=DbRXnPBBuvCdNiMreIR68KKaIzcse3CJzutIeHxwXo2R/H303fkRzD9i/17yDRrst8BH7n dedyMjjo4D+ixLak6QF9c+wnWCeo+qo88DKDITBiWZSue2ZZ3cKI5yg8m5OLsGhn7SrCKF h53S5CKeiNFbLBnSIFaGCgtVgbPjLYUvi/Urd890bKg8j1W01Sw9fTStuts76IGVLMZqld d3pIUWAIHzJcTyXN1DxDbtgINPSGXl25n3liFX1JesbhfBdzYkZ6dMZc5AXkQSiHT7IvLa 5IV8jTMRXFaep4PoL1c3RgNgOyDLtP6H+xaNZXdBO6DFtwNqGdn44bmTj059Vw== Archived-At: Subject: [IPsec] WGLC for draft-ietf-ipsecme-yang-iptfs 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, 16 Aug 2021 18:18:50 -0000 This is the start of 2 week WGLC on the draft-ietf-ipsecme-yang-iptfs document, ending 2021-08-31. 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 Aug 16 11:19:47 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 563A53A1040 for ; Mon, 16 Aug 2021 11:19:45 -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 (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 YwPRd0oeT_cY for ; Mon, 16 Aug 2021 11:19:43 -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 2ABB93A1049 for ; Mon, 16 Aug 2021 11:19:43 -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 lahtoruutu.iki.fi (Postfix) with ESMTPSA id C8D7C1B00241 for ; Mon, 16 Aug 2021 21:19:40 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1629137980; 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=mpXq2IyAj/i5wSbNXwCspVFDjQNmWUdIxEsSmBGoBfM=; b=fbEAV0uKKw5mtvH+rz9NjoyAKeetCOtrmzzj/Yta0XIc6ulGyYRDZ1H5sMl8TCgP0sLrZe AfYBdJOyH3j/B3vaqDsn5qgduXbyL81VqsLcYLwVNmlPcSUwP6SOi0M9fUaKZvEIJzMHzJ otFTqJ8M9Bv4FMkUFQqU33icmErOynqjFa3+R8krI2GFh0uVj2cIpqb/Nl3g18Kom0GF2B Fgdq/T3ePND3bRdVmupb3zU+8XuxSftXFq/UEU7qwoxaKkYB9ri5cKH8isiYFUGCeoVeZd CYkupZ7QLetEYXR08zw8q+3I6o2BmM5Uw0O4PbG2WXlic+J85HxV9jNQR5JaVA== Received: by fireball.acr.fi (Postfix, from userid 15204) id 69F9525C12D0; Mon, 16 Aug 2021 21:19:40 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24858.44092.407860.392035@fireball.acr.fi> Date: Mon, 16 Aug 2021 21:19:40 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 1 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=1629137980; 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=mpXq2IyAj/i5wSbNXwCspVFDjQNmWUdIxEsSmBGoBfM=; b=GzwhNLw2vcX0Y6zmre9IIS5M79IAazy1hoxx932LK5Q9nIWntYrcmEGZbGiKY+Fkp9m1De e4dprF4Bc7QKOHQLDO6fCRsc22cn/X0PA+JkDeb093LyLOdMba+GVGjhi5yv1yGJqF1FfI VKUhrVRcdqJ2iyGdMw//IxRvlsyRJodsk3RywfW9PPgLRrM94MZ9SzKTiCNpaXx0MKLSeI +Iabl4JmAAPOueJt14qPSpDMu1oSjEj9lgBYkILXUhEOi84tY+SBtaB4Nk4how1gha+llP 9mlGgQg5DlL0Jzv7jozZOnXrAXRDvkwfi4UbDlWKxoY9wvmueX9l8BVfqd+RNw== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1629137980; a=rsa-sha256; cv=none; b=ADSicBCEeuROlYFbn6Gb/FI3bwnLM/Oj6DW0QcGHiqgsYZEAnqfsbEkiu7Wg6/LpewcPqW /Lf/CBNWvH7NMwabkowIH7ZOH7WvH40DAScmcDZw/NjB/zRWESo84LVSsD9oDcitXL2ijO uuwJRaicz62j2T3xFEnXG7u9N3ZGRmTVYEhEa0Ufp1mXgySFpzxnIl/f0sQmX3FZQtKEqw Ta+WnARrKqxLp1UptIQFUtg/g8Zq3odQ6g9BW2uWfynJpxAVYv9+hIF6wGzf1pifO9Y+14 Dp8ReAsnkfvGt3E8hIy8DSV9j/iIn4EuN0BulY/j6b/5Jtz2fXG2s+bxQ+X3ww== Archived-At: Subject: [IPsec] WGLC for draft-ietf-ipsecme-mib-iptfs 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, 16 Aug 2021 18:19:46 -0000 This is the start of 2 week WGLC on the draft-ietf-ipsecme-mib-iptfs document, ending 2021-08-31. 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 Aug 16 11:51:57 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 2E5E13A19E4 for ; Mon, 16 Aug 2021 11:51:55 -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 LveXyaq-TiCT for ; Mon, 16 Aug 2021 11:51:50 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id EAC7B3A19E0 for ; Mon, 16 Aug 2021 11:51:49 -0700 (PDT) Received: from smtpclient.apple (047-026-251-217.res.spectrum.com [47.26.251.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id DF4E5803DF; Mon, 16 Aug 2021 18:51:48 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Christian Hopps In-Reply-To: <24858.42061.118149.546106@fireball.acr.fi> Date: Mon, 16 Aug 2021 14:51:47 -0400 Cc: ipsec@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <41C188CD-9B34-4FD9-A9B9-632C335253A4@chopps.org> <24858.42061.118149.546106@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3654.100.0.2.22) 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, 16 Aug 2021 18:51:55 -0000 > On Aug 16, 2021, at 1:45 PM, Tero Kivinen wrote: >=20 > Christian Hopps writes: >> During the last IETF meeting it was agreed that we would move >> quickly to resolve any issues that Tero had left, and get this >> document submitted to the IESG. So asking again if the new version >> (published prior to the meeting) satisfied the issues so we can move >> forward? >=20 > No. You did not address any of my concerns there. I am not even sure > if you read my email where I presented my concerns, as I have not seen > any other comment on them than except complaining that this is not > meant for low bandwith situations and my examples using them were not > interesting. >=20 > Last week when I was reading your draft I got really disappointed when > I noticed that section 2.5 was completely unchanged, when you did say > you had addressed my comments. I got so annoyed, that I decided to > wait before sending my reply as I know how hard it is write > constructive text when you are annoyed. >=20 > You seemed way too much concentrating on my example using slow link > speed, and not to the fact that section 2.5 (implictly) requires you > to wait for packets to drop out of reorder window before they can be > processed at all: I believe I was focused on slow links b/c it seemed that you were = focused on a concern of =E2=80=9Clarge delays=E2=80=9D, and the only = large delays happen if there are slow links or inappropriately large = reorder windows. In any case the revised text talks to these points. > Essentially the section 2.5 says that you first reorder, and wait for > all missing packets and finally processes the in-order payload streams > to extract the inner-packets. >=20 >> =46rom my original email: >=20 > ---------------------------------------------------------------------- > If we do allow forwarding complete packets in out of order manner, > what should we do in case packet O<24> is lost? Should we allow > forwarding I<7> immediately when we received O<25>, or do we need to > wait 4 more seconds to see whether O<24> ever arrives before we deem > both I<5> and I<6> as lost (because fragments of them are lost), and > send I<4> and I<7> forward? >=20 > If we do allow processing of outer packets in that kind of out of > order manner, then that will of course mean that there might be > reordering happening because of this, and this most likely needs to be > mentioned in the draft too. >=20 > On the other hand I would assume that in normal cases lost packets are > much more common than reordered packets, but there are most likely > cases where there is lots of reordering, but not that much of lost > packets. > ---------------------------------------------------------------------- >=20 > I.e., I want section 2.5 to explictly mention how to do processing of > the AGGFRAG_PAYLOADS, i.e., is receiver allowed to forward parts of > the inner packets out even when previous packets are missing, and they > of course need to wait until all piecess of large fragmented packets > arrive before they can forward it, but can they send packets that were > in the first packet which did arrive out immediately when they arrive > (I would assume yes), and if some packets are missing in the middle, I > would assume that they can extract the inner-packets from later > packets too even when there is some packets missing. >=20 > The last paragraph of 2.5 which says: >=20 > Finally, the receiver processes the now in-order AGGFRAG_PAYLOAD > payload stream to extract the inner-packets (Section 2.2.3, > Section 6.1). >=20 > would indicate that you do require full completele in-order payload > stream before you start extracting any inner-packets from the stream, > meaning that for every single lost or reordered frame you need to > stall until that frame drops out of reordering window to make sure > they have in-order payload stream. Only after the packet drops out > from the reorder window they can be sure it was lost thus only after > that they know they do have in-order stream that do have some gaps in > it. >=20 > So adding text saying "Receiver MAY process any completely received > inner-packets immediately they are fully received." would solve a lot > of problems, but of course that would contradict the last paragraph > which do say we process inner-packets only in order. >=20 > Also if we do allow processing inner-packets immediately when we have > received full packet inside the AGGFRAG_PAYLOAD payload stream this > may will cause the reordering which happened in the outer transport to > be duplicated for inner-packets too, so we should most likely add note > for that. >=20 > If we do not allow processing inner-packets immediately but must wait > until all the packets are received and the missing packet drops out of > reorder buffer that will cause us to create extra buffering and extra > burstines, so then we should add note about that. We certainly did not want to specify whether an implementation SHOULD = forward complete inner packets, out of order, or not, b/c that is not = required for interoperability. Implementations could very well decide to = offer one or both options. Our job is to specify the on-the-wire = behavior so that implementations interoperate. You are suggesting that we should add a =E2=80=9CMAY=E2=80=9D to the = same affect though. That seems like a non-controversial change that = could be made. Adding a more text pointing out the obvious results of this choice = (i.e., that sending inner packets early can create downstream out of = order delivery, or that waiting for outer packets can add delay and = bursti-ness) would not be my preference. As a general rule I try (and = I=E2=80=99m not alone in this) to avoid adding unneeded text, b/c the = best you can hope for is to not say it wrong. That said if you believe = the text must also include these 2 points as well i will add them in = order to move things forward. Would you be agreeable to just adding the clarifying =E2=80=9CMAY=E2=80=9D= statement? Thanks, Chris. > --=20 > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Aug 16 13:24:36 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 24AF93A0E25 for ; Mon, 16 Aug 2021 13:24:34 -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 tQgAvA4yUS2G for ; Mon, 16 Aug 2021 13:24:29 -0700 (PDT) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 E52BF3A0E23 for ; Mon, 16 Aug 2021 13:24:28 -0700 (PDT) Received: by mail-ed1-x534.google.com with SMTP id n12so28292291edx.8 for ; Mon, 16 Aug 2021 13:24:28 -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=mmj6WvOtB3IAQ7g2eIWKUOqVRmMwQOyvON1i5MsSGYQ=; b=fJwAsyCzCB8dE77fl6kAtqGtd+49zc46WwaUZMsaRYreZJ2F5WN04oeRuXKMLyWfjH 900dBocFB9wQVwBggkwjjlmVVb37z8co5mEACOrOHPk4HHi/wgoB2FFAUTPw92dMCne0 Sf/Rti6bgcBWfFU3oEor/luRcg+ILPo57efRg= 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=mmj6WvOtB3IAQ7g2eIWKUOqVRmMwQOyvON1i5MsSGYQ=; b=D1KY/hG09iN7HrrYS8Ay+4iCGU2rnG9XmZ4bQfL46sHEdoDzGfAfyY1vyvLJS7YNll 1tTBfhMaqQ1H2y8/KVDOCZJ4usaShTY+D7e/DAzJGVdcb4HXXNhVNIpJbzAdGxA3f8wK YSui9T+iuaT5lmHb/bz+4ccOo1AUyH0m1t4j6Ts5s9NJ1zlRoH3HzVlgckMsHfdOQcEy Rp89roJaQDQlZG6US6d9N6/W6PWk+QkADbwLoonHC1mOySDqmSefAdKhA5JREc36Yh1c VL6A6x6CLWPMdFKwrBiHNYAjzR/SwVFSBd6Ys84iUGXLkqUrdpsNRkGGdQZ0LuJnzrAW L4PA== X-Gm-Message-State: AOAM532sbA/TNWIYQ1Qir+vCaE9zMdnBIjptBkjEyE1l8G8Uvyc2eY0G FyuGjnIUcfaUnVt6bxSilRmcIw== X-Google-Smtp-Source: ABdhPJxs1yyalFAmKMqwXIncRneFuWTBbUfGtk5VDcLpijqVPNlzHFHNqOnIeKDXrkxT7m6iMbd/Ow== X-Received: by 2002:aa7:df98:: with SMTP id b24mr402948edy.103.1629145466062; Mon, 16 Aug 2021 13:24:26 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca. [193.110.157.194]) by smtp.gmail.com with ESMTPSA id d19sm95262ejj.122.2021.08.16.13.24.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Aug 2021 13:24:25 -0700 (PDT) Date: Mon, 16 Aug 2021 16:24:22 -0400 (EDT) From: Paul Wouters To: Valery Smyslov cc: 'Paul Wouters' , 'Tero Kivinen' , "ipsec@ietf.org WG" In-Reply-To: <1ced01d78558$c3696700$4a3c3500$@gmail.com> Message-ID: <78be2fbb-5efa-826e-b593-1a7194ec34f4@nohats.ca> References: <24831.15134.45575.357305@fireball.acr.fi> <6bca2d7d-a061-148b-bbdb-1783e72a936@nohats.ca> <1ced01d78558$c3696700$4a3c3500$@gmail.com> 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: Mon, 16 Aug 2021 20:24:34 -0000 On Fri, 30 Jul 2021, Valery Smyslov wrote: [ replying as I got prompted by Tero on this regarding WGLC ] >> 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. I guess this all still feels like a bit of a kludge. I wonder if there is a way to do this with one new transform type, and an ordered list of proposals inside. I understand the desire to specify order, but I feel the current method is fragile and error prone. Eg if one end has Additional Key Exchange 1 = SIKE_P434, Additional Key Exchange 2 = FRODOKEM_640_AES and the other end has Additional Key Exchange 1 = FRODOKEM_640_AES, Additional Key Exchange 2 = SIKE_P434, where both might not really care which goes first or second. I think it would be worth thinking about this problem a bit more. > 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. Then please say it clearly, instead of implying it. >> 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. Sure, but it would be best if such a new document would not need to Updates: this document just for this one little change. So why not: - Each IKE_INTERMEDIATE exchange MUST bear exactly one key exchange method. + All Additional Key Exchanges MUST be in their own Exchange - that is + these KE's cannot be exchanged via a single IKE message exchange. I also just realised that Addtional Key Exchange is not the best term for this, as it is very close to Internet Key Exchange and people might think this is a chain of IKEv2 and something else. Maybe "Additional KE Exchange" would be better? > 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. I tried to phrase it above, but I think it can be improved upon further. >> 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. That makes it clearer, but. If each Additional Key Exchange carries a None, does that mean it these Exchanges can be fully omitted and we are only doing DH/KE from IKE_SA_INIT ? What if the Additional Key Exchange 1 contains None, and there is an Additional Key Exchange 2 ? Does it mean that everything can still be skipped ? I'm still not a big fan of the specification this way. I wish we could find a way to do this in one new transform type and somehow enforcing an ordered list. >> 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". Understood. >> 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. Please please please include some asci art of this exchange in IKE_SA_INIT. I ensure you that will make it much more easy for a new reader to understand this. > (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. I'm not convinced this is a valid reason to break open the clear state of CREATE_CHILD_SA and a REKEYed IKE SA. This is really unpleasant for our state machine. >> 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. Again, then why not simply use the MSGID of the corresponding CREATE_CHILD_SA ? >> 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. Understood (but see above) >> 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. Okay. >> 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? I'm lost here too now. But I think however something workds if it saves state and reboots should not affect the protocol design? >> 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. Well yes. If the initiator is broken, the connection might fail. I don't think we need to guard against that. >> 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. I think this just complicates things too much. We shouldn't have confused peers or forgetful peers. Just hard fail when something unexpected happens. assert() for the win :P >> 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? I can try. >> 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. so this was again me being confused about the entire mechanism of the draft. This is why I strongly urge you to add some ascii art about how these payloads flow (as part of the SA payload) >> 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. Okay. >> 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. Okay. >> 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 :-) While we might be in agreement, we are in disagreement on why the other approach was discarded :) So the real question is, should it be considered? I do think that this document needs some more work to clarify things, and I would really like to see more people reviewing this document as well. I would also like to see a discusion of a "simpler" design that would not use 4 Transform Type's, but only 1, and see if that would be "simpler" (simpler in quotes twice because i can't evaluate yet without such discussion which would be the simpler solution. Paul From nobody Mon Aug 16 14:09: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 0750B3A122F for ; Mon, 16 Aug 2021 14:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.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 1d9y_C65ons8 for ; Mon, 16 Aug 2021 14:09:45 -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 223173A122C for ; Mon, 16 Aug 2021 14:09:44 -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 meesny.iki.fi (Postfix) with ESMTPSA id 2BCD520050; Tue, 17 Aug 2021 00:09:40 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1629148180; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vTDVKHB3DwTll5BBERra5FnbiqZ2OKPVzQpSJEsUVtc=; b=D5smxbA0tedGptMfXKP7SxxoiBWKljOU72XMyTw8WPPYBRoWT4lIQvOIwl7N39EAYuaCC3 /4aV85Qrc5FrtKePO4GYmLOyYqYrpFFR17Hck2HE95WCnw/LdlqnsssLH3PxWf52ejJd3n KR0JH0AmeWEf/jBIbXdacN4PX5Gof64= Received: by fireball.acr.fi (Postfix, from userid 15204) id 3F3FB25C12D0; Tue, 17 Aug 2021 00:09:39 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <24858.54291.205079.485517@fireball.acr.fi> Date: Tue, 17 Aug 2021 00:09:39 +0300 From: Tero Kivinen To: Christian Hopps Cc: ipsec@ietf.org In-Reply-To: References: <41C188CD-9B34-4FD9-A9B9-632C335253A4@chopps.org> <24858.42061.118149.546106@fireball.acr.fi> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 15 min X-Total-Time: 14 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1629148180; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vTDVKHB3DwTll5BBERra5FnbiqZ2OKPVzQpSJEsUVtc=; b=HIoMyRnp06gY/vU2hG8he9aZbPLhXDPXhNCty2p3sYQKMUDZkeqTHTPSCjSC/YahZKg8/H 5oPh8p6e3UDrijYRQxABsz5GLQ0rYHkPHF9VrszaJ4FO6eWgegvypzKkXfyj0kcax3m+Yk exAhdlpj7D/YmZ1Oss16OXfA1z23ppU= ARC-Seal: i=1; s=meesny; d=iki.fi; t=1629148180; a=rsa-sha256; cv=none; b=ly8chXnajpqrnBbUyFtAEtWws9JnhwrC0HnlAAygOTIY8Pm+GLr5BQ4gmG8GgN5m7ascL8 AP4qs7Tcg0YI6hWV2JAjR5RU+rNLO78wp2PsyEAXQlbSGLtuAyTL6Ue4rmXFzCMsujFKAZ 8bYTeCSE8tq9NTv1QvEixbFm4Nbex0M= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi 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, 16 Aug 2021 21:09:49 -0000 Christian Hopps writes: > We certainly did not want to specify whether an implementation > SHOULD forward complete inner packets, out of order, or not, b/c > that is not required for interoperability. My reading is that current text says you MUST NOT forward complete inner packets until all earlier packes have been received and you are sure you have been able to sort the outer packets to in-order, and you can only do that after the missing packets have dropped out of reorder window. > Implementations could very well decide to offer one or both options. > Our job is to specify the on-the-wire behavior so that > implementations interoperate. I disagree on that. We also want implementations to do sane and smart things, it is not just enough that they interoperate. Also specifying recipient processing is good way to verify that your transmit processing is also correct. I am working also on the IEEE and they always say that they do not specify receivers, they only specify transmitters, as implementing receiver is left as exercise for the reader, and can simply be done by "reversing" what transmitter does. This cause cases where they send two variable length strings in one frame, without delimieters or lenght fields and do not notice this as they only specify transmitter. This is easy to implement on the transmiter end but impossible to implement on the receiver... Or in one case where their channel hopping sequence was selected by calculating the hash of the packet. Very easy to do on the transmitter as he has the packet. Bit harder to do on the receiver end as he would need to be constantly trying all possible channel hopping sequences and trying to see if any of them forms a packet... I have always considered it very good that in the IETF we do try to mandate or at least give instructions for the receiver end too. That makes it much easier to do interoperable implemenations. > You are suggesting that we should add a =E2=80=9CMAY=E2=80=9D to the = same affect > though. That seems like a non-controversial change that could be > made. Yes, I propose changing the MUST NOT to MAY... > Adding a more text pointing out the obvious results of this choice > (i.e., that sending inner packets early can create downstream out of > order delivery, or that waiting for outer packets can add delay and > bursti-ness) would not be my preference. It might be obvious to you, but it might not be obvious to the person doing the actual implementations. I always consider it a good idea to point out pitfalls and cases where implementor should be vary to the implementor and not to assume that implementor actually realizes this.=20= > As a general rule I try (and I=E2=80=99m not alone in this) to avoid = adding > unneeded text, b/c the best you can hope for is to not say it wrong. If you add unneeded text and find out later that it was then that was good thing, as it clearly indicated that the text in question was not clear enough. Adding more text that clarifies things is good thing.=20 > That said if you believe the text must also include these 2 points > as well i will add them in order to move things forward. I think it would be worth explaining, as it might also cause the implementor to think which option to choose. I.e., if he is more concerned about the reordering, and do not care about the burstiness or delays he will pick one option, but if he care more about the latency he will pick another option.=20 > Would you be agreeable to just adding the clarifying =E2=80=9CMAY=E2=80= =9D > statement=3F I think adding explaination about what the effects the two options for MAY have is something that is good thing to add too. --=20 kivinen@iki.fi From nobody Mon Aug 16 14:22:55 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 332D53A1331 for ; Mon, 16 Aug 2021 14:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 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_H4=0.001, RCVD_IN_MSPIKE_WL=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=dell.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 DGgi1qmndAn3 for ; Mon, 16 Aug 2021 14:22:50 -0700 (PDT) Received: from mx0a-00154904.pphosted.com (mx0a-00154904.pphosted.com [148.163.133.20]) (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 9321D3A132E for ; Mon, 16 Aug 2021 14:22:50 -0700 (PDT) Received: from pps.filterd (m0170390.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 17GL7RMs030151; Mon, 16 Aug 2021 17:22:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=smtpout1; bh=mt5svvCQsY5NTOBrq1naj6zq87LLSmGC5WHFQBmy4KA=; b=ahkO9UxvoNzWZTU3M/Uov57bKI4tzG/zbCfnKU1Av5RrJLgMbj0Kup7BN3TnwPyEb2aw 4U4g3iBYG+C5kT0XGOR1S/3Bcujskh5q4cBHVyS1YDm2tkwsXbf4FajTrXSSPbDv2CkY YzXJTkd6Y1QjfWfmYn4+9auTI5AQcB5OzY5G7FovEelyEA7fgwx0gpgeM0ADRIuOSdh3 dBD6V8940mCw+gmYT2V6MIS6DvKbsXknO0AtiyLVCQDzzD9CwIQTuemf4vfsLs66zZts TM6pCZqw7qbjHe2M5L4Up8OK5kiRMfMXTQ+Q8cfOnsyIDKq4K41u3ohJ35I9PRcHc12l jA== Received: from mx0a-00154901.pphosted.com (mx0a-00154901.pphosted.com [67.231.149.39]) by mx0a-00154904.pphosted.com with ESMTP id 3afnx12dgr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 Aug 2021 17:22:49 -0400 Received: from pps.filterd (m0142699.ppops.net [127.0.0.1]) by mx0a-00154901.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 17GL4tWE164539; Mon, 16 Aug 2021 17:22:48 -0400 Received: from nam04-mw2-obe.outbound.protection.outlook.com (mail-mw2nam08lp2169.outbound.protection.outlook.com [104.47.73.169]) by mx0a-00154901.pphosted.com with ESMTP id 3afmafj9c9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 16 Aug 2021 17:22:48 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=j6ZkBre3Crw8pddGqKkAyc0zFqMS2JnyPipM8sdyg8G/Zu5/0ZOCaGmVqvWTHu3L3tPoxS6kJs53GoXZ4z55nldrdutP1s7NLPSYcDrbq1DYu1VryEIR1mzAUOlhUIvOr5Lz8jQl9chKM59DNL1o7fQw7EVxqVgXItU/qqRdxaoIb1p/O8lqBkYklZ+JWYn5QoCgf8wHsJEDAd9ARfqzQAYcRXO0RhLEJX01BdkXCZ4+DdGOhWTllFv9j4pxYLLDaXwGwYhamt3tCuYdO63iEbJzdRKXa7vUFhzNxUGqxmR5gauj2sT1uMYWvDp2Vlo98X0QPtx64CR9RoeQlFqIiQ== 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=mt5svvCQsY5NTOBrq1naj6zq87LLSmGC5WHFQBmy4KA=; b=jmmgakQ3DSzdImVK+qB/qLPz9sc0ioA7ZHRsOcw75L5cFEdV14tDDpk7WWQVW3A28GSm+Tp4K/TCVV9XG/vg9RY9OJcd/gmI/VaHnrnMyyk3FHAibZy3usZP+hPSpG9DVCmQH+xEDWQAshBINDggflH59cGV6n/RCELrCRLqnmJTNRYgiLlaCTmt9Kcu0X63pfbI9mbuCQMN2P/zPrTdgIK1mjQLY0ZUwN4cl4kNg7hU5i5kQhPLI7N3K1mOa4WjeL4RBbrolklab8gqHmKyEI7PFGat4IxG4awPE2NHIVVSFUJzDz/rauS5TZSd/u3jnKo29/SyD55tf3CJqzSzsA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com; dkim=pass header.d=dell.com; arc=none Received: from SA0PR19MB4508.namprd19.prod.outlook.com (2603:10b6:806:b8::7) by SA0PR19MB4319.namprd19.prod.outlook.com (2603:10b6:806:8a::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4415.15; Mon, 16 Aug 2021 21:22:47 +0000 Received: from SA0PR19MB4508.namprd19.prod.outlook.com ([fe80::c904:cd5b:5d13:526]) by SA0PR19MB4508.namprd19.prod.outlook.com ([fe80::c904:cd5b:5d13:526%3]) with mapi id 15.20.4415.023; Mon, 16 Aug 2021 21:22:47 +0000 From: "Koning, Paul" To: Tero Kivinen CC: Christian Hopps , "ipsec@ietf.org" Thread-Topic: [IPsec] iptfs publication request Thread-Index: AQHXWVkRjrxZT4WvlE6uBldSb5aue6s0Ma+AgEIE4ACAAKPXgIAAEm+AgAAmhYCAAAOqAA== Date: Mon, 16 Aug 2021 21:22:47 +0000 Message-ID: <04158312-E6F2-4467-B435-58D77ED7435E@dell.com> References: <41C188CD-9B34-4FD9-A9B9-632C335253A4@chopps.org> <24858.42061.118149.546106@fireball.acr.fi> <24858.54291.205079.485517@fireball.acr.fi> In-Reply-To: <24858.54291.205079.485517@fireball.acr.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3654.120.0.1.13) authentication-results: iki.fi; dkim=none (message not signed) header.d=none;iki.fi; dmarc=none action=none header.from=Dell.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c80d1cf6-f168-442f-d3d3-08d960fbfeb1 x-ms-traffictypediagnostic: SA0PR19MB4319: x-microsoft-antispam-prvs: x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4 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: WgTWAFxw5sxWac4GlMvHfzLFd3pFQgfidofkjVtbrpeHb7Z6RxiZ/l9aYacRgmrS1ILIQkEnNMvcNDTOREZS4vlKtskMgzwCyIzUoxNo6rxOjlOqpixbk+zpk13pBMa3bE9eeI4SJ7h7VBruXBgxI3HRQiEgEAchhgjFQ5EojB6U84S6ng/66dPgCmBzdE7eXnoI1iXmhg5/zGsFoDYr3Fzr2+Y3ZI2xqf3ttS1y/cDHBFYOZqRyflHIgyLXw0gxjV7V1qXQM8TDKJ3t7Qd0QqHKDS0ALFwki63zgaaCNguSeqFR9ksDLzvRodcoE3hDM8ZXvOKwaVc/GNqF+Y3+3nge9oWQJV8QHwjsUV1iuHSdv/6GfpBwo4K7FDIVHuWGEI59S63RxthSx4mlDa3e/SSfxQ9lNR4DV3uUWgAFVhcflVUzWcIZG+doSAQQIabK0KsEyk/URTES8vYkEm2H93P+ZfcDkvWzIen031NN2VxxWq0rUiYvG51cLxfhih+ZxztahreADZx8kNXTN4ApHD0RK023TAL1oYtTNmhDWwE7FrbsfZ9DSmnZXi+TXAE/JyCkXIPVOT6zsAO7gPHEltyGdvaAVeD9ouTaKyOGexDqAhXvTmVy6UG13l7ysMLSyAZausRdc57T4atw9G1mIjpMwuSKMCfmzeAB7oWqXDhRvTz8NBVkt2hp7pTHPayN2svVD6X77RJeTwmETpJFeuMtnoqB8DIy+16oHOZvc8eJUkEvN2FHPmBtWaZLDOIB x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA0PR19MB4508.namprd19.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(136003)(39860400002)(366004)(396003)(346002)(53546011)(86362001)(33656002)(6486002)(6506007)(4744005)(5660300002)(478600001)(186003)(8676002)(26005)(83380400001)(2616005)(2906002)(8936002)(66556008)(64756008)(6916009)(66446008)(54906003)(38070700005)(66946007)(6512007)(38100700002)(36756003)(786003)(71200400001)(316002)(4326008)(122000001)(76116006)(91956017)(66476007)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?SHEasC+BPbYzZhUoeA1+8thC1R9/MdHbta/WpuA0cNadb0IVgSNcQ5K2CynO?= =?us-ascii?Q?8CIhpSGgBVfJmUlGBqMedsbLn9R8OUcplrVs3tXhJhVjM2awaIqjudve6gpQ?= =?us-ascii?Q?MZMF331ZhF2yTavNXVhEAZ6WMuP6Fl3NMXD/hVF+mcc6bszIjr7TLlM7xj9e?= =?us-ascii?Q?Bsf4DX8A5V6HlTXzUJPRqY39JxYY5SAKYAuIgIkhxMim27dxbF7QxghOwz7O?= =?us-ascii?Q?13Nh48R5Z6qefqoaBJ50CDtd5KfyJlsrrPDjV10/GM5sYaP3b+Pn7RO8acE4?= =?us-ascii?Q?sQJushEvi7dAlxkysq7NMizgmjsv+JJi8Nk+LGnNlZLSCUQQGxwAO9QruIB5?= =?us-ascii?Q?rmWNb0EEvhXeRmzFZ6KkoHU4gvU2sV/JyRxEY5JUyNKRm0sCUc2eV06xlPDG?= =?us-ascii?Q?WfGRXmMp7ZISCwbsd+2V/Dku5xwXz/hSBsMZlI2EgN0sgP2fP1fOV32x+sAK?= =?us-ascii?Q?9+5IOAgW26InOXYYwCi/7g1aROPrmukqv1sHFBSZqkRzYAh6/rWwoHwLhg3O?= =?us-ascii?Q?L+ITwKMleLrem4pz5qeXnMD5/6pmSyTCC1JVF0wIkuzOZA46M+tImCgENTT5?= =?us-ascii?Q?jWsM1qmjtty+yg6BanJ35hoOjpleE/zY/WVGEb/7hc3btD/7731w/vR/SLH/?= =?us-ascii?Q?/tFt5BasqLCXq5sDx2TqaPSjcyz8DKWzEz/lIdBWiTEnI+MmkdPNV9zbr/rA?= =?us-ascii?Q?ZLMj18lltTpBY55ylsKJEfPPix8VHGeKLGQ3reQO/ozJV884xDi6OcH9po7v?= =?us-ascii?Q?cVbwoqHiKCwXiyx3Hz8KkmetN/HhP8zY4xLIDcIrz5715O5nMUYRE4x4VLn1?= =?us-ascii?Q?ypbn+BABGDcbGAJ+pSWbrtD1GXysfTY9DlIiEpaW3o+YiSFzOIwHzk+F1CNn?= =?us-ascii?Q?M7NRtjCbIsFSfTctMjCoDRnzvRT2sQIvCUjmTYqhIPeg3BGoXZ65/d/c/9qm?= =?us-ascii?Q?lo5aS4yBvFO5UgoeAySRbboGgtvNmINcZzJLx7gU9iidSKi8vlhtLwHgGRja?= =?us-ascii?Q?ZsOJg05Q5nyYUJo9+t+EZ9YrOikqGhYxUHvullZqO0IK7rffEaLLdoo+nDyq?= =?us-ascii?Q?3rA1qcL5fbAxxeRfSxSfNeViSO41lpNpzHQ73CkwhLxGY/uz17s4wr7oWKIe?= =?us-ascii?Q?T0KuWU0TKULj6NsFXGCDbRtYqHxssQltER3hvBnXvHCGjcNNDLVlWPZEm7qy?= =?us-ascii?Q?Kxi8ooXh+fTEV/bNYY2C/1hKJ1Vs/YeBMuAiNe8gEfDEw8OuY9Pjak0xfLGE?= =?us-ascii?Q?nxUjMMDtRvWlRSZdgJ7Bd3pmMGn9v9NNIMKvBQStKxYzjoZ3SP+u6No31PLl?= =?us-ascii?Q?YWcS09Ig3R+1PEJEoO5d0TfM?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-ID: <9693C2FACBA92045BA90DB152B17462B@namprd19.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Dell.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA0PR19MB4508.namprd19.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c80d1cf6-f168-442f-d3d3-08d960fbfeb1 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2021 21:22:47.4615 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: VGpscDJ/CtZd61QAiEqsVSZcm58bC6qeGS2+OQBZyHMzKzces2ucYTc24ZstnWlZCmjPSYGTJqa7WoDFeUbSnA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR19MB4319 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-16_08:2021-08-16, 2021-08-16 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 clxscore=1011 priorityscore=1501 spamscore=0 phishscore=0 impostorscore=0 suspectscore=0 mlxscore=0 lowpriorityscore=0 bulkscore=0 adultscore=0 mlxlogscore=609 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2108160134 X-Proofpoint-GUID: iOgxY8wmf8LpHXRvTRp_8J4U9e-2S9h1 X-Proofpoint-ORIG-GUID: iOgxY8wmf8LpHXRvTRp_8J4U9e-2S9h1 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxlogscore=758 malwarescore=0 mlxscore=0 adultscore=0 phishscore=0 spamscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2108160134 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, 16 Aug 2021 21:22:53 -0000 > On Aug 16, 2021, at 5:09 PM, Tero Kivinen wrote: >=20 > ... >> Adding a more text pointing out the obvious results of this choice >> (i.e., that sending inner packets early can create downstream out of >> order delivery, or that waiting for outer packets can add delay and >> bursti-ness) would not be my preference. >=20 > It might be obvious to you, but it might not be obvious to the person > doing the actual implementations. I always consider it a good idea to > point out pitfalls and cases where implementor should be vary to the > implementor and not to assume that implementor actually realizes this.=20 I agree with that sentiment. The way I look at standards (protocol specifications in particular) is that= conformance should imply interoperability. If you give the spec to two pe= ople and ask them to implement what's in the spec, and they follow the stat= ed rules, the result should be two implementations that interoperate. paul From nobody Mon Aug 16 17:50:34 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B11E73A074E for ; Mon, 16 Aug 2021 17:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3v1_K1xpnhM for ; Mon, 16 Aug 2021 17:50:27 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id A0A2D3A076E for ; Mon, 16 Aug 2021 17:50:27 -0700 (PDT) Received: from smtpclient.apple (047-026-251-217.res.spectrum.com [47.26.251.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id A306B80CC2; Tue, 17 Aug 2021 00:50:26 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Christian Hopps In-Reply-To: <04158312-E6F2-4467-B435-58D77ED7435E@dell.com> Date: Mon, 16 Aug 2021 20:50:25 -0400 Cc: Tero Kivinen , "ipsec@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <509B58FB-03A1-4C28-BE47-1E4A47478512@chopps.org> References: <41C188CD-9B34-4FD9-A9B9-632C335253A4@chopps.org> <24858.42061.118149.546106@fireball.acr.fi> <24858.54291.205079.485517@fireball.acr.fi> <04158312-E6F2-4467-B435-58D77ED7435E@dell.com> To: "Koning, Paul" X-Mailer: Apple Mail (2.3654.100.0.2.22) 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: Tue, 17 Aug 2021 00:50:32 -0000 > On Aug 16, 2021, at 5:22 PM, Koning, Paul = wrote: >=20 >=20 >=20 >> On Aug 16, 2021, at 5:09 PM, Tero Kivinen wrote: >>=20 >> ... >>> Adding a more text pointing out the obvious results of this choice >>> (i.e., that sending inner packets early can create downstream out of >>> order delivery, or that waiting for outer packets can add delay and >>> bursti-ness) would not be my preference. >>=20 >> It might be obvious to you, but it might not be obvious to the person >> doing the actual implementations. I always consider it a good idea to >> point out pitfalls and cases where implementor should be vary to the >> implementor and not to assume that implementor actually realizes = this.=20 >=20 > I agree with that sentiment. This is the specific case here: =E2=80=9CGiven an ordered packet stream, A, B, C, if you send B before A = you will be sending packets in a different order=E2=80=9D Again I=E2=80=99ll put this text to unblock this document, but really, = sometimes things *are* obvious. Thanks, Chris. > The way I look at standards (protocol specifications in particular) is = that conformance should imply interoperability. If you give the spec to = two people and ask them to implement what's in the spec, and they follow = the stated rules, the result should be two implementations that = interoperate. >=20 > paul >=20 >=20 From nobody Tue Aug 17 03:49:06 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 2D9F63A077F for ; Tue, 17 Aug 2021 03:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.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=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 lrBgOPJOa9Cj for ; Tue, 17 Aug 2021 03:48:57 -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 542E33A0776 for ; Tue, 17 Aug 2021 03:48:57 -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 4C1551B00273; Tue, 17 Aug 2021 13:48:53 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1629197333; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Kuc1KMjt078YgnkvR3QfJCFj8wHEq/+NazKlmfpsF4A=; b=YizoGxAJ/4yUUYfNRZu3QSGi5rxgoXD+ijCJ4+/yKvDTsGUTMUmNcdJ2ni+StgrJ1HWib1 XFeeUGv5OWEr5pgw37B39a/J9EhgFA5hs3GVoSjcuBwgAw04DZH07/r9FFmVrdmiaswEoG sh9DA2j27CmfYvn0XRxTkg91bojGF6q6SGsfp6L/0wlPV+FWfhgrhCvyKTyi37Q4PcRuD9 iQdQUnxmXIcWM+CbFxWEN8bzapgExkkn1W4gkTeXTj+tkRV6fjdwt3r5aFIdAntBp+FwTK lAzaiA+TaHrq8oitvlXAaT7glZgNiM0DReCXdeEk6d/47lqH9/WBha1CSeWaEA== Received: by fireball.acr.fi (Postfix, from userid 15204) id E03F425C12D0; Tue, 17 Aug 2021 13:48:52 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <24859.37908.612701.587580@fireball.acr.fi> Date: Tue, 17 Aug 2021 13:48:52 +0300 From: Tero Kivinen To: Christian Hopps Cc: "Koning\, Paul" , "ipsec\@ietf.org" In-Reply-To: <509B58FB-03A1-4C28-BE47-1E4A47478512@chopps.org> References: <41C188CD-9B34-4FD9-A9B9-632C335253A4@chopps.org> <24858.42061.118149.546106@fireball.acr.fi> <24858.54291.205079.485517@fireball.acr.fi> <04158312-E6F2-4467-B435-58D77ED7435E@dell.com> <509B58FB-03A1-4C28-BE47-1E4A47478512@chopps.org> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 22 min X-Total-Time: 21 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=1629197333; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Kuc1KMjt078YgnkvR3QfJCFj8wHEq/+NazKlmfpsF4A=; b=TXfpz5LZB2d0DjhgwjTK31uHP2GRhKLuNKt0DpeH4w1uuFZC8W7o74/o2lV15xB7AB+7hH Oq2xaFKlsKZrzc+SFt5jQImBo1C5Bt40dZcLpCo5wwmqZme4nwETnjhsmqWVIhcuFXnqTW nnRUhaqmPk3wKtwtxuJO4sdHTyJIQdOzgmpj2QSfGM/x/P5ptI3ofw/sS+B9xWyrwj8a1D EweApOoRgDIIP450aCBUMLJMPh9ykksNf+z0IpIN6RCQ+KdSDP19667ZSLD4RaziNfg5kP bmMfVtWrE95oodq1pmGfllE0pi6zok5aUdrZHm/Dn02AJ32kPL6LUKbCg0zS5g== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1629197333; a=rsa-sha256; cv=none; b=r+Z7SBAP7uFpctVvIlv8NoV+swDGWn3C/DkbxMYK3+GqrWO0cz5ZuTM2gDVfXRVj+Aaf6k 0pQGQKNsYvc/FjmM6gNYzHhaDH38TrHzc6YmvkDu0d7pqOLAtbnonw+Caukcc3RrgApzcs VI8JRLceRkX7dwR24ivjroxxvT+p1epBeIsEZfctv6r2qrRqhlWtOLJTO6SR/M5S91bZPH d5mM3udtKN7/E6ZgItb5pTzCRaPojS1Ht10qyy/MHsZA+JKDLatabAg+/aUARmDYdQvEQ9 vkz2Mcg4kSvqxsKASHcbo/yvpdsQMtD4w2czWgKt+ozEXTDqyj9YDANEW4F0aQ== 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: Tue, 17 Aug 2021 10:49:05 -0000 Christian Hopps writes: > >> It might be obvious to you, but it might not be obvious to the per= son > >> doing the actual implementations. I always consider it a good idea= to > >> point out pitfalls and cases where implementor should be vary to t= he > >> implementor and not to assume that implementor actually realizes t= his.=20 > >=20 > > I agree with that sentiment. >=20 > This is the specific case here: No it is not. > =E2=80=9CGiven an ordered packet stream, A, B, C, if you send B befor= e A you > will be sending packets in a different order=E2=80=9D The question there is that it is very hard to see from the text in current draft section 2.5 that it can cause extra 32-1000 packets (reorder window size) of buffering for every single lost packet. And that current text does not allow the sending packets in different order, as it does not allow processing packets in any other order than in-order. So there are multiple choises here, which affect how the implementation behaves: 1) Make sure that packets are processed in-order always, i.e., do not allow any outer packets to be processed until you are sure they are in-order thus causing extra buffering/latency if any packet is lost, as you need to wait for that packet to drop out of reorder window before you know it is lots, thus before you can continue processing packets. This will not cause any reordering of packets. 2) Process incoming outer packets as they come in, and do not reorder them before processing. In that case you need to process outer packets partially, i.e., only send those inner packets out which have been fully received, but buffer those pieces of inner packets which are still missing pieces as outer packets were either lost or reordered. In this case if there is reordering in the outer packets this will cause this reordering on the inner packets too. 3) Do hybrid version where when you notice missing packet on the outer packets you postpone processing of it for short duration and to see the reordering was only very small (for example wait for just next outer packet). If the outer packet stream can be reordered inside this small window you do that and process packets in order and send them out in order, but you limit the latency caused by this to for example only for one packet and if larger reordering is happening then you still buffer wait until the full reorder window until you deem that you are not able to process that inner packet as it was not completely received because of missing packet. The current text only allows option 1, and I would like to allow options 2 and 3 and perhaps also others, but I would also like to have some text explaining the trade offs of different options. This does not affect the interoperability as such, as two implementations using different methods will interoperate, but this might cause very bad performance issues. Actually I think option 1 (the one only allowed now) can and will cause large jitter for round trip times for every single lost frame. I am not sure what large jitter of round trip times does for different protocols running inside the tunnel. I would assume that any kind of audio conferencing system would have really bad performance if run over such system. > Again I=E2=80=99ll put this text to unblock this document, but really= , > sometimes things *are* obvious.=20 I had to parse the section 2.5 several times before I realised that it do really require me to process packets in-order i.e., it forbids options 2 and 3. It might be obvious for you, but it was not obvious for me, and I think that restriction do make the performance really bad. --=20 kivinen@iki.fi From nobody Tue Aug 17 06:15:46 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 229B73A15F0 for ; Tue, 17 Aug 2021 06:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzV5XF5lErka for ; Tue, 17 Aug 2021 06:15:40 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id EB9573A15D9 for ; Tue, 17 Aug 2021 06:15:39 -0700 (PDT) Received: from smtpclient.apple (047-026-251-217.res.spectrum.com [47.26.251.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 40029803DE; Tue, 17 Aug 2021 13:15:39 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Christian Hopps In-Reply-To: <24859.37908.612701.587580@fireball.acr.fi> Date: Tue, 17 Aug 2021 09:15:38 -0400 Cc: "Koning, Paul" , "ipsec@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <41C188CD-9B34-4FD9-A9B9-632C335253A4@chopps.org> <24858.42061.118149.546106@fireball.acr.fi> <24858.54291.205079.485517@fireball.acr.fi> <04158312-E6F2-4467-B435-58D77ED7435E@dell.com> <509B58FB-03A1-4C28-BE47-1E4A47478512@chopps.org> <24859.37908.612701.587580@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3654.100.0.2.22) 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: Tue, 17 Aug 2021 13:15:45 -0000 Hi Tero, Let=E2=80=99s keep things simple here at this point in the process, and = also match the results we have already verified with running code. We can add more text that talks directly about how the reorder widnow = size should be kept as small as possible (it should NEVER be 1000 = packets, I=E2=80=99m not sure where you got 1000 from but that=E2=80=99s = not a reasonable number so perhaps pointing this out IS important). It = should be something between 0 and 5 perhaps 10 if you want to really = handle wild cases of reordering (you probably dont). Regular packet loss kills TCP etc.. we do not need to optimize the = protocol for this condition; however, this brings me to the next point: We are not transport experts here and we need to stay away from straying = into that area. We had this draft reviewed and approved by the transport = area (the experts) because of this. We should not start getting into = transport area issues of describing affects on the network of jitter or = re-ordered or lost packets etc. This is not our expertise and will only = cause trouble when this comes before the transport area AD. We have approved text from the transport experts now (in addition to = clearing WG LC). I do not want to open this draft back up for major = modifications that start talking about new ways to handle packets and = their affects on the drownstream network etc. This is not our area of = expertise, and we have already received approval from the experts for = the text that we have. Let=E2=80=99s stick with the approved text and = make clarifying modifications only. Thanks, Chris. > On Aug 17, 2021, at 6:48 AM, Tero Kivinen wrote: >=20 > Christian Hopps writes: >>>> It might be obvious to you, but it might not be obvious to the = person >>>> doing the actual implementations. I always consider it a good idea = to >>>> point out pitfalls and cases where implementor should be vary to = the >>>> implementor and not to assume that implementor actually realizes = this.=20 >>>=20 >>> I agree with that sentiment. >>=20 >> This is the specific case here: >=20 > No it is not. >=20 >> =E2=80=9CGiven an ordered packet stream, A, B, C, if you send B = before A you >> will be sending packets in a different order=E2=80=9D >=20 > The question there is that it is very hard to see from the text in > current draft section 2.5 that it can cause extra 32-1000 packets > (reorder window size) of buffering for every single lost packet. >=20 > And that current text does not allow the sending packets in different > order, as it does not allow processing packets in any other order than > in-order. >=20 > So there are multiple choises here, which affect how the > implementation behaves: >=20 > 1) Make sure that packets are processed in-order always, i.e., do > not allow any outer packets to be processed until you are sure they > are in-order thus causing extra buffering/latency if any packet is > lost, as you need to wait for that packet to drop out of reorder > window before you know it is lots, thus before you can continue > processing packets. This will not cause any reordering of packets. >=20 > 2) Process incoming outer packets as they come in, and do not > reorder them before processing. In that case you need to process > outer packets partially, i.e., only send those inner packets out > which have been fully received, but buffer those pieces of inner > packets which are still missing pieces as outer packets were either > lost or reordered. In this case if there is reordering in the outer > packets this will cause this reordering on the inner packets too. >=20 > 3) Do hybrid version where when you notice missing packet on the > outer packets you postpone processing of it for short duration and > to see the reordering was only very small (for example wait for just > next outer packet). If the outer packet stream can be reordered > inside this small window you do that and process packets in order > and send them out in order, but you limit the latency caused by this > to for example only for one packet and if larger reordering is > happening then you still buffer wait until the full reorder window > until you deem that you are not able to process that inner packet as > it was not completely received because of missing packet. >=20 > The current text only allows option 1, and I would like to allow > options 2 and 3 and perhaps also others, but I would also like to have > some text explaining the trade offs of different options. This does > not affect the interoperability as such, as two implementations using > different methods will interoperate, but this might cause very bad > performance issues. >=20 > Actually I think option 1 (the one only allowed now) can and will > cause large jitter for round trip times for every single lost frame. I > am not sure what large jitter of round trip times does for different > protocols running inside the tunnel. I would assume that any kind of > audio conferencing system would have really bad performance if run > over such system. >=20 >> Again I=E2=80=99ll put this text to unblock this document, but = really, >> sometimes things *are* obvious.=20 >=20 > I had to parse the section 2.5 several times before I realised that it > do really require me to process packets in-order i.e., it forbids > options 2 and 3. >=20 > It might be obvious for you, but it was not obvious for me, and I > think that restriction do make the performance really bad. > --=20 > kivinen@iki.fi >=20 From nobody Tue Aug 17 06:22:10 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 B83333A193E for ; Tue, 17 Aug 2021 06:22:07 -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 WvfKdmNNldVf for ; Tue, 17 Aug 2021 06:22:02 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id B773F3A1932 for ; Tue, 17 Aug 2021 06:22:02 -0700 (PDT) Received: from smtpclient.apple (047-026-251-217.res.spectrum.com [47.26.251.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 0E283803DE; Tue, 17 Aug 2021 13:22:02 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Christian Hopps In-Reply-To: Date: Tue, 17 Aug 2021 09:22:01 -0400 Cc: "Koning, Paul" , "ipsec@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <9BD66C9D-9E6C-4BEC-A71F-D74B667EA503@chopps.org> References: <41C188CD-9B34-4FD9-A9B9-632C335253A4@chopps.org> <24858.42061.118149.546106@fireball.acr.fi> <24858.54291.205079.485517@fireball.acr.fi> <04158312-E6F2-4467-B435-58D77ED7435E@dell.com> <509B58FB-03A1-4C28-BE47-1E4A47478512@chopps.org> <24859.37908.612701.587580@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3654.100.0.2.22) 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: Tue, 17 Aug 2021 13:22:08 -0000 In particular why don=E2=80=99t we simply indicate that a lost packet = can induce a delay of the fixed packet interval times the window size - = 1, and so the widow size should be kept to a minimum, and leave it at = that. Thanks, Chris. > On Aug 17, 2021, at 9:15 AM, Christian Hopps = wrote: >=20 > Hi Tero, >=20 > Let=E2=80=99s keep things simple here at this point in the process, = and also match the results we have already verified with running code. >=20 > We can add more text that talks directly about how the reorder widnow = size should be kept as small as possible (it should NEVER be 1000 = packets, I=E2=80=99m not sure where you got 1000 from but that=E2=80=99s = not a reasonable number so perhaps pointing this out IS important). It = should be something between 0 and 5 perhaps 10 if you want to really = handle wild cases of reordering (you probably dont). >=20 > Regular packet loss kills TCP etc.. we do not need to optimize the = protocol for this condition; however, this brings me to the next point: >=20 > We are not transport experts here and we need to stay away from = straying into that area. We had this draft reviewed and approved by the = transport area (the experts) because of this. We should not start = getting into transport area issues of describing affects on the network = of jitter or re-ordered or lost packets etc. This is not our expertise = and will only cause trouble when this comes before the transport area = AD. >=20 > We have approved text from the transport experts now (in addition to = clearing WG LC). I do not want to open this draft back up for major = modifications that start talking about new ways to handle packets and = their affects on the drownstream network etc. This is not our area of = expertise, and we have already received approval from the experts for = the text that we have. Let=E2=80=99s stick with the approved text and = make clarifying modifications only. >=20 > Thanks, > Chris. >=20 >=20 >=20 >=20 >> On Aug 17, 2021, at 6:48 AM, Tero Kivinen wrote: >>=20 >> Christian Hopps writes: >>>>> It might be obvious to you, but it might not be obvious to the = person >>>>> doing the actual implementations. I always consider it a good idea = to >>>>> point out pitfalls and cases where implementor should be vary to = the >>>>> implementor and not to assume that implementor actually realizes = this.=20 >>>>=20 >>>> I agree with that sentiment. >>>=20 >>> This is the specific case here: >>=20 >> No it is not. >>=20 >>> =E2=80=9CGiven an ordered packet stream, A, B, C, if you send B = before A you >>> will be sending packets in a different order=E2=80=9D >>=20 >> The question there is that it is very hard to see from the text in >> current draft section 2.5 that it can cause extra 32-1000 packets >> (reorder window size) of buffering for every single lost packet. >>=20 >> And that current text does not allow the sending packets in different >> order, as it does not allow processing packets in any other order = than >> in-order. >>=20 >> So there are multiple choises here, which affect how the >> implementation behaves: >>=20 >> 1) Make sure that packets are processed in-order always, i.e., do >> not allow any outer packets to be processed until you are sure they >> are in-order thus causing extra buffering/latency if any packet is >> lost, as you need to wait for that packet to drop out of reorder >> window before you know it is lots, thus before you can continue >> processing packets. This will not cause any reordering of packets. >>=20 >> 2) Process incoming outer packets as they come in, and do not >> reorder them before processing. In that case you need to process >> outer packets partially, i.e., only send those inner packets out >> which have been fully received, but buffer those pieces of inner >> packets which are still missing pieces as outer packets were either >> lost or reordered. In this case if there is reordering in the outer >> packets this will cause this reordering on the inner packets too. >>=20 >> 3) Do hybrid version where when you notice missing packet on the >> outer packets you postpone processing of it for short duration and >> to see the reordering was only very small (for example wait for just >> next outer packet). If the outer packet stream can be reordered >> inside this small window you do that and process packets in order >> and send them out in order, but you limit the latency caused by this >> to for example only for one packet and if larger reordering is >> happening then you still buffer wait until the full reorder window >> until you deem that you are not able to process that inner packet as >> it was not completely received because of missing packet. >>=20 >> The current text only allows option 1, and I would like to allow >> options 2 and 3 and perhaps also others, but I would also like to = have >> some text explaining the trade offs of different options. This does >> not affect the interoperability as such, as two implementations using >> different methods will interoperate, but this might cause very bad >> performance issues. >>=20 >> Actually I think option 1 (the one only allowed now) can and will >> cause large jitter for round trip times for every single lost frame. = I >> am not sure what large jitter of round trip times does for different >> protocols running inside the tunnel. I would assume that any kind of >> audio conferencing system would have really bad performance if run >> over such system. >>=20 >>> Again I=E2=80=99ll put this text to unblock this document, but = really, >>> sometimes things *are* obvious.=20 >>=20 >> I had to parse the section 2.5 several times before I realised that = it >> do really require me to process packets in-order i.e., it forbids >> options 2 and 3. >>=20 >> It might be obvious for you, but it was not obvious for me, and I >> think that restriction do make the performance really bad. >> --=20 >> kivinen@iki.fi >>=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Aug 17 06:38: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 9A20E3A0D0F for ; Tue, 17 Aug 2021 06:38:02 -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 o4a4poP7wUYY for ; Tue, 17 Aug 2021 06:37:58 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id F22CC3A0D06 for ; Tue, 17 Aug 2021 06:37:57 -0700 (PDT) Received: from smtpclient.apple (047-026-251-217.res.spectrum.com [47.26.251.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id D6122803DE; Tue, 17 Aug 2021 13:37:56 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Christian Hopps In-Reply-To: <9BD66C9D-9E6C-4BEC-A71F-D74B667EA503@chopps.org> Date: Tue, 17 Aug 2021 09:37:56 -0400 Cc: "Koning, Paul" , "ipsec@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8B9B2CB1-D470-45AD-9C9A-218FB3DBE811@chopps.org> References: <41C188CD-9B34-4FD9-A9B9-632C335253A4@chopps.org> <24858.42061.118149.546106@fireball.acr.fi> <24858.54291.205079.485517@fireball.acr.fi> <04158312-E6F2-4467-B435-58D77ED7435E@dell.com> <509B58FB-03A1-4C28-BE47-1E4A47478512@chopps.org> <24859.37908.612701.587580@fireball.acr.fi> <9BD66C9D-9E6C-4BEC-A71F-D74B667EA503@chopps.org> To: Tero Kivinen X-Mailer: Apple Mail (2.3654.100.0.2.22) 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: Tue, 17 Aug 2021 13:38:03 -0000 I also need to point out that we are only talking about the case where = the implementation doesn=E2=80=99t use a timer to timeout missing = packets. We specifically added text highlighting that implementations = are free to timeout missing packets much earlier if they so choose. = Perhaps we should also highlight this again?? Thanks, Chris. > On Aug 17, 2021, at 9:22 AM, Christian Hopps = wrote: >=20 > In particular why don=E2=80=99t we simply indicate that a lost packet = can induce a delay of the fixed packet interval times the window size - = 1, and so the widow size should be kept to a minimum, and leave it at = that. >=20 > Thanks, > Chris. >=20 >> On Aug 17, 2021, at 9:15 AM, Christian Hopps = wrote: >>=20 >> Hi Tero, >>=20 >> Let=E2=80=99s keep things simple here at this point in the process, = and also match the results we have already verified with running code. >>=20 >> We can add more text that talks directly about how the reorder widnow = size should be kept as small as possible (it should NEVER be 1000 = packets, I=E2=80=99m not sure where you got 1000 from but that=E2=80=99s = not a reasonable number so perhaps pointing this out IS important). It = should be something between 0 and 5 perhaps 10 if you want to really = handle wild cases of reordering (you probably dont). >>=20 >> Regular packet loss kills TCP etc.. we do not need to optimize the = protocol for this condition; however, this brings me to the next point: >>=20 >> We are not transport experts here and we need to stay away from = straying into that area. We had this draft reviewed and approved by the = transport area (the experts) because of this. We should not start = getting into transport area issues of describing affects on the network = of jitter or re-ordered or lost packets etc. This is not our expertise = and will only cause trouble when this comes before the transport area = AD. >>=20 >> We have approved text from the transport experts now (in addition to = clearing WG LC). I do not want to open this draft back up for major = modifications that start talking about new ways to handle packets and = their affects on the drownstream network etc. This is not our area of = expertise, and we have already received approval from the experts for = the text that we have. Let=E2=80=99s stick with the approved text and = make clarifying modifications only. >>=20 >> Thanks, >> Chris. >>=20 >>=20 >>=20 >>=20 >>> On Aug 17, 2021, at 6:48 AM, Tero Kivinen wrote: >>>=20 >>> Christian Hopps writes: >>>>>> It might be obvious to you, but it might not be obvious to the = person >>>>>> doing the actual implementations. I always consider it a good = idea to >>>>>> point out pitfalls and cases where implementor should be vary to = the >>>>>> implementor and not to assume that implementor actually realizes = this.=20 >>>>>=20 >>>>> I agree with that sentiment. >>>>=20 >>>> This is the specific case here: >>>=20 >>> No it is not. >>>=20 >>>> =E2=80=9CGiven an ordered packet stream, A, B, C, if you send B = before A you >>>> will be sending packets in a different order=E2=80=9D >>>=20 >>> The question there is that it is very hard to see from the text in >>> current draft section 2.5 that it can cause extra 32-1000 packets >>> (reorder window size) of buffering for every single lost packet. >>>=20 >>> And that current text does not allow the sending packets in = different >>> order, as it does not allow processing packets in any other order = than >>> in-order. >>>=20 >>> So there are multiple choises here, which affect how the >>> implementation behaves: >>>=20 >>> 1) Make sure that packets are processed in-order always, i.e., do >>> not allow any outer packets to be processed until you are sure they >>> are in-order thus causing extra buffering/latency if any packet is >>> lost, as you need to wait for that packet to drop out of reorder >>> window before you know it is lots, thus before you can continue >>> processing packets. This will not cause any reordering of packets. >>>=20 >>> 2) Process incoming outer packets as they come in, and do not >>> reorder them before processing. In that case you need to process >>> outer packets partially, i.e., only send those inner packets out >>> which have been fully received, but buffer those pieces of inner >>> packets which are still missing pieces as outer packets were either >>> lost or reordered. In this case if there is reordering in the outer >>> packets this will cause this reordering on the inner packets too. >>>=20 >>> 3) Do hybrid version where when you notice missing packet on the >>> outer packets you postpone processing of it for short duration and >>> to see the reordering was only very small (for example wait for just >>> next outer packet). If the outer packet stream can be reordered >>> inside this small window you do that and process packets in order >>> and send them out in order, but you limit the latency caused by this >>> to for example only for one packet and if larger reordering is >>> happening then you still buffer wait until the full reorder window >>> until you deem that you are not able to process that inner packet as >>> it was not completely received because of missing packet. >>>=20 >>> The current text only allows option 1, and I would like to allow >>> options 2 and 3 and perhaps also others, but I would also like to = have >>> some text explaining the trade offs of different options. This does >>> not affect the interoperability as such, as two implementations = using >>> different methods will interoperate, but this might cause very bad >>> performance issues. >>>=20 >>> Actually I think option 1 (the one only allowed now) can and will >>> cause large jitter for round trip times for every single lost frame. = I >>> am not sure what large jitter of round trip times does for different >>> protocols running inside the tunnel. I would assume that any kind of >>> audio conferencing system would have really bad performance if run >>> over such system. >>>=20 >>>> Again I=E2=80=99ll put this text to unblock this document, but = really, >>>> sometimes things *are* obvious.=20 >>>=20 >>> I had to parse the section 2.5 several times before I realised that = it >>> do really require me to process packets in-order i.e., it forbids >>> options 2 and 3. >>>=20 >>> It might be obvious for you, but it was not obvious for me, and I >>> think that restriction do make the performance really bad. >>> --=20 >>> kivinen@iki.fi >>>=20 >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Aug 17 08:21: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 341E63A1F6A for ; Tue, 17 Aug 2021 08:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.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=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 SOMa-bbqkSgK for ; Tue, 17 Aug 2021 08:21:13 -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 1736C3A1F64 for ; Tue, 17 Aug 2021 08:21:12 -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 lahtoruutu.iki.fi (Postfix) with ESMTPSA id 2497D1B00273; Tue, 17 Aug 2021 18:21:10 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1629213670; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9wwzlrnXAzpP3DdScFyon6RpWpvbRwSYx5RvOTTSc54=; b=EIgrh4Z7+MArf7n2EWZVNuxCR5CD1Fjp4/7Hfzg1YCsSeXRxVuMkA0puVZ5CR1g955023N 8d5ujHzwrTwk1CpoafyYnaVSsuzfV+5wriBkXMRkzX3DYaSQKPo5pbNZa+KiM/qARjjZKw nKGVyLOHtoQPDpQZGSHvz31xO2QTHRoZXtNxTOpVImSYrNnJuQoMCS/dqDuC2Z6IQ55FJD 6csug6WEuFD2KuMnitJd8ntdvd7UOQtPOjTCkbUWXTclq5EoPzF65yBC2icGAfv8R2arul imPBZrocpjDscLaF1lCyTkiRawH0TjudjYAA91k016jEQnylBcDgoEusibf1eQ== Received: by fireball.acr.fi (Postfix, from userid 15204) id 9DFE025C12D0; Tue, 17 Aug 2021 18:21:09 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <24859.54245.590825.284241@fireball.acr.fi> Date: Tue, 17 Aug 2021 18:21:09 +0300 From: Tero Kivinen To: Christian Hopps Cc: "Koning\, Paul" , "ipsec\@ietf.org" In-Reply-To: References: <41C188CD-9B34-4FD9-A9B9-632C335253A4@chopps.org> <24858.42061.118149.546106@fireball.acr.fi> <24858.54291.205079.485517@fireball.acr.fi> <04158312-E6F2-4467-B435-58D77ED7435E@dell.com> <509B58FB-03A1-4C28-BE47-1E4A47478512@chopps.org> <24859.37908.612701.587580@fireball.acr.fi> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 26 min X-Total-Time: 31 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=1629213670; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9wwzlrnXAzpP3DdScFyon6RpWpvbRwSYx5RvOTTSc54=; b=ifHOHzTowKDoSj4Lu3frUXspDoZQDevRlLj1W6xB9E+c/07rrNJYhBmKg4R/PJMkZKWboc pz0/yrNsn2k3cV/hCDM32mmMvWY7CaeM9fRC+FRNb4U3dz4AGo4YZl4iZRwvqe20HxpLpX /QHPPMDDyh6JeMDdeCN1T6l+zWdE+0bS9FZUJ6BrQRPUjEhCJl/UAneP+A9IQhKLpGFupF 1kH1p3om1XtfneY09AaqOkU5wYO2+4G9m4hqJsRf39H8sQ6OnBg4fXG/VItyOU9pHj117L J3ohf9zniodpLnqEMKfv7L6l9k3DFf7Jc1MwMpBfFZJjvfrjtDfzoU6eeS2R5A== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1629213670; a=rsa-sha256; cv=none; b=XtzmksIOjHhdTz/pkDMFtNuyPpv8KVfIEMx2FWfUBFZykxo0L7aKZBlAIl1iowzkdeOl03 EMc29HMdG0549NyUKq2t2j1aBBckVUsAx8kH6Zh95I8dHwFrsyvgMyWmOC4w7vJkXEVWiI WNpealBpPemicRRq6Kn3A5HPETTpFISMZrXN//bZBHv+Fvmf2O3VBc1DeXgm8wmHDDY04a WD/B+sLh10FY0wIzUVQRAt6IMrHcTXnSmLmIm0cie6j/Oj2srhnLoq8gRR3eC0H2gY6fmP hoe8l8zJxp8ZOFCZdqAgT1R8r1vk5VeiQVvXiT9RmPoO7fJbHPMobsvKm0LsZA== 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: Tue, 17 Aug 2021 15:21:17 -0000 Christian Hopps writes: > Let=E2=80=99s keep things simple here at this point in the process, a= nd also > match the results we have already verified with running code.=20 In real production use over internet or in the lab between two test machines (or inside one datacenter between machines there)=3F > We can add more text that talks directly about how the reorder > widnow size should be kept as small as possible (it should NEVER be > 1000 packets, I=E2=80=99m not sure where you got 1000 from but that=E2= =80=99s not a > reasonable number so perhaps pointing this out IS important). It > should be something between 0 and 5 perhaps 10 if you want to really > handle wild cases of reordering (you probably dont). Reorder and replay windows are linked as there is no point of having replay window of 1000 packets if your reorder window is only few packets, as any packets which gets delayed more than that few packets which are accepted by replay window will be thrown away by reorder window, thus there is no point of having bigger replay window than reorder window. Minimum replay window size required for each implementation is 32, and I think that is very common default case, even though RFC4303 recommends window size of 64. From RFC4303 section 3.4.3: A minimum window size of 32 packets MUST be supported when 32-bit sequence numbers are employed; a window size of 64 is preferred and SHOULD be employed as the default. Another window size (larger than= the minimum) MAY be chosen by the receiver. (The receiver does NOT notify the sender of the window size.) The receive window size should be increased for higher-speed environments, irrespective of assurance issues. Values for minimum and recommended receive window= sizes for very high-speed (e.g., multi-gigabit/second) devices are not specified by this standard. On fast links people want to increase that, as any packet which gets delayed will get delayed a lot when counted in packets as even delay of few tens of ms will mean there is lots of packets gone during that time. Actually I think it would be better to say that "replay window size MUST be larger than reorder window size." and also add text that says that if packet is out of reorder window (but was inside replay window as otherwise it would have never reached re-ordering process) the implementation can process the compelete inner packets from that packets even when partial packets inside that outer packets cannot be processed. The replay window will take care that this is not an attack, so it is safe to process such packets even when they are outside replay window. Of course if it is outside replay window that means we can't reassmeble partial packets that are part of that outer packet, but we can safely process the inner packets completely inside that outer packet.=20 Adding text about that to the section 2.5 would also make the protocol better.=20 > Regular packet loss kills TCP etc.. we do not need to optimize the > protocol for this condition; however, this brings me to the next > point: I do not belive so. I regularly use TCP over crappy mobile networks and they do have lots of packet loss. TCP works fine in such situations. It is not very fast, but it do work... I have no idea how it would work when each packet loss would not be a simple packet loss, but also a long delay before the further packets in the stream are being received (i.e., waiting for the reorder buffer to fill up before sending packets after the lot packet). I would assume selective ACK and such mechanism in TCP will not really work, but I am not expert, so I can't say that for sure. This would require someone from the transport area to comment, how well will TCP work when we randmly have extra 10x or 100x delay for packet transition and then we get lots of packet back to back.. > We are not transport experts here and we need to stay away from > straying into that area. We had this draft reviewed and approved by > the transport area (the experts) because of this. We should not > start getting into transport area issues of describing affects on > the network of jitter or re-ordered or lost packets etc. This is not > our expertise and will only cause trouble when this comes before the > transport area AD. True, but I am not sure if the transport area reviewer actually understood the behavior we have specified now. I did not understood that on my first reading. > We have approved text from the transport experts now (in addition to > clearing WG LC). I do not want to open this draft back up for major > modifications that start talking about new ways to handle packets > and their affects on the drownstream network etc. This is not our > area of expertise, and we have already received approval from the > experts for the text that we have. Let=E2=80=99s stick with the appro= ved > text and make clarifying modifications only. When we find an issue in early phases of the document development (WGLC is still very early in the document development), we should address those. Also the section in 2.5 was written in such way that I myself did not understand the implications of the words "Finally, the receiver processes the now in-order AGGFRAG=5FPAYLOAD payload stream to= extract the inner". I always assumed that we could process outer packets as they come in, and did not have to do stop and wait until we have confirmed that we have in-order stream (with perhaps some packets missing) before we continue processing. On the other hand it is true that we do get another transport are review during the last call phase, and we can of course ask this specific question from the reviewer at that time, but I think solving this problem now is better than during the IETF wide last call. --=20 kivinen@iki.fi From nobody Tue Aug 17 08:31:46 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 CA5D73A1FC4 for ; Tue, 17 Aug 2021 08:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.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=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 IjH_2JDbEr8O for ; Tue, 17 Aug 2021 08:31:41 -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 1C4E63A1FC1 for ; Tue, 17 Aug 2021 08:31:40 -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 405061B00273; Tue, 17 Aug 2021 18:31:36 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1629214296; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rcrua27YvrfpmYB0YYKYxN2cjigxuvPKzdi+e1OXKGg=; b=i0fslcWvSFrWoUjKOy/NMURpOOFlg1fJg8Rh83RUF388e37Rjz/7SGMQbUPj5KdDMvSFUs Z+LNP27i5g60ZqW7QAq5yxEC/tYHE5WmJW9bx26uBKX+10zvs2fYcKXMc0Qt/QOEsGUOSn DxXJdq7eL6lxZdTimGtgDPlhenU2nrOV21lCHb5NUxmbpBi19shQ3qKRKce556y5XmgO5I HcJgQI9PhyKuvf3p8e0fYeBzhayOvtQ91D+ufSR+4stawnbEKLxeFW+v+jUysaBa03goOZ utkKQ0Q2kRPLppuQCCG0ZW8iVkYT4Cd8kor1RPulJLk6TKyTlZOpLc7LtqQCww== Received: by fireball.acr.fi (Postfix, from userid 15204) id 02EAB25C12D0; Tue, 17 Aug 2021 18:31:36 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <24859.54871.450251.579682@fireball.acr.fi> Date: Tue, 17 Aug 2021 18:31:35 +0300 From: Tero Kivinen To: Christian Hopps Cc: "Koning\, Paul" , "ipsec\@ietf.org" In-Reply-To: <9BD66C9D-9E6C-4BEC-A71F-D74B667EA503@chopps.org> References: <41C188CD-9B34-4FD9-A9B9-632C335253A4@chopps.org> <24858.42061.118149.546106@fireball.acr.fi> <24858.54291.205079.485517@fireball.acr.fi> <04158312-E6F2-4467-B435-58D77ED7435E@dell.com> <509B58FB-03A1-4C28-BE47-1E4A47478512@chopps.org> <24859.37908.612701.587580@fireball.acr.fi> <9BD66C9D-9E6C-4BEC-A71F-D74B667EA503@chopps.org> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 11 min X-Total-Time: 10 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=1629214296; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rcrua27YvrfpmYB0YYKYxN2cjigxuvPKzdi+e1OXKGg=; b=iPZBvwdCGhfA7z3hiieyWDU6tal6EtXz+wkd4zSp3+Dxfy/JhqJz8jzQFdBP8iAFgtwN5a y2ORO3vqnWovHeshl2lmsVTuIhu3ajtJ/JcdCTNNm+sV1W1dqsJZ/o9yQzLzaGh/+dutdS y3eHOJlH0oJ79AOI4J5Qem7g0STNJ5B4NHVnYI6MGkrfTCxCvxpPIDZ6XY9mnsqPRTeYDT UJf1K9PnQVBFCSdwq95ib2dL5eQL+egXRA5orofwF8Vgl7GL+z0PR6uqoBspmQFI1KYnLE UxrUqHCnIyX32h3wpx9EE35mk/dWJS2lrphV1FQseVvjZzAb3hCMGatUtqfZxA== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1629214296; a=rsa-sha256; cv=none; b=T9NPQklmJhruhcIDAV7QzACQXKPslG6sy/ytpy5JNQy9TlT6tGy/mYc9RneK1M49Jw1Y74 KCrh2klXAPpu/J2ythR2eKtwhxlDWgK5pk7JnL/R3W2HJxBRI2gyPBG78HWmDrchX36EGS nDeXenJkq3+q8dGRTlHoEFe7gT5+BNFy40njFqmV5gcwebjT7IYy0lX03PCQLLyKgRabCQ W2ykxW8jDXo0RWc21IiA49aF5tyQl5gzZcJ5cqkiuJjLXtDe7uDZU/O9XpKekIQywB+a57 R4j62Dy2npHQZO0qEW371P9t9Y3q0Az8s3X80De9klFvgb3rFWCBWGnw9e1IUQ== 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: Tue, 17 Aug 2021 15:31:44 -0000 Christian Hopps writes: > In particular why don=E2=80=99t we simply indicate that a lost packet= can > induce a delay of the fixed packet interval times the window size - > 1, and so the widow size should be kept to a minimum, and leave it > at that.=20 As the window size is configured by the adminstrator and adminstrator has no idea how it will affect things. We can't really expect adminstrators to understand that when they have decide that they have hundreds of GBs of memory in their VPN machines, that configuring the reorder buffers and replay windows to 100000 packets long (absurdly large value, but its just few gigabytes of memory for those buffers so who cares about the memory consumption) that will suddenly cause really long delays for all packets if any single packet is ever lost. If the network is as reliable as you assume they always are and you almost never loose packets it might take very long until this happens and when it happens suddenly their whole network freezes until the reorder buffer is filled up and then dumped to the network in one huge burb. This would be really bad behavior and most likely that would cause them to submit bug reports to the implementations and implemetors would blame the adminstrators for putting such stupid values in and adminstrators would blame implementors for allowing such things and not having warnings in the manual of not doing so, and implementors said they did not realize that would happen as RFC did not say so. If we do not explain why window size should be kept mimimum having such text there does not mean anything. And I assume the usable minimum would be the same than for minimum replay window size that must be supported, i.e., 32 packet, which can still cause 32x of normal delay for every lost packet. --=20 kivinen@iki.fi From nobody Tue Aug 17 08:37: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 A37F33A2019 for ; Tue, 17 Aug 2021 08:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.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=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 77QYYEDU7WU8 for ; Tue, 17 Aug 2021 08:37:40 -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 C10983A2006 for ; Tue, 17 Aug 2021 08:37:40 -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 3C50A1B00273; Tue, 17 Aug 2021 18:37:33 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1629214653; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=phAXMq0EnYXiwmCqV73RFSbtANHjtDdQjq15nt5FUk4=; b=fzXoI1Vh5PmJ2C2MUSw0kARIEhMc7xtgX/0fkBVaBhtQIodIoyP321b4GAaDsk2z6IcotB GA9KIV99r8Nizx+63V3b8OOPBhbFkBg9az/Z29nOaUUCJ6GpHgNok7MUFRTudK9gU2Br4v OiMVTmrUt0urDXnsxGxvyXVKg+A0CETww2x1VN0ErJENplpoMPhI7tYFMOXhorsga8kL7D kMxGqneP3fWrjqreUs6H9AdXNv89DQwcwi5Jz2raLQZZ4Dn2RtGxzFeoBCvfMRJh4NWJ/A YXw54xXmkFY0sTm6zrfcPIocuyONMXwJ09h1aTQim1Wu7U8+tIeFzC3RHZcuyw== Received: by fireball.acr.fi (Postfix, from userid 15204) id 08F2325C12D0; Tue, 17 Aug 2021 18:37:33 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <24859.55228.954532.765168@fireball.acr.fi> Date: Tue, 17 Aug 2021 18:37:32 +0300 From: Tero Kivinen To: Christian Hopps Cc: "Koning\, Paul" , "ipsec\@ietf.org" In-Reply-To: <8B9B2CB1-D470-45AD-9C9A-218FB3DBE811@chopps.org> References: <41C188CD-9B34-4FD9-A9B9-632C335253A4@chopps.org> <24858.42061.118149.546106@fireball.acr.fi> <24858.54291.205079.485517@fireball.acr.fi> <04158312-E6F2-4467-B435-58D77ED7435E@dell.com> <509B58FB-03A1-4C28-BE47-1E4A47478512@chopps.org> <24859.37908.612701.587580@fireball.acr.fi> <9BD66C9D-9E6C-4BEC-A71F-D74B667EA503@chopps.org> <8B9B2CB1-D470-45AD-9C9A-218FB3DBE811@chopps.org> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 5 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=1629214653; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=phAXMq0EnYXiwmCqV73RFSbtANHjtDdQjq15nt5FUk4=; b=tjZpP77u6LNgJP6SChul9bTsDeizDdWtz4XT5LyqGOXXFtBB0kB6vR5r1W742VEh1IX/dX LFoGsqEvoYz86UmmXZllTtmiDVRDaoklwZmj7u4YNnA34P4Bp0tsZnAMVUREYA1QSF4Uqo BbhwCXVEmeRpv7uUp5Y2ZrjYybVxTrXgN1Exiu0bh7G9LA7T7US3eGbdwUGE9wkT9gZ422 knQJHigU1pi9hsjCD1yrWu58QitFbkfzLjNrirzH195tdosLHAxHyd0Np+/DFZPS1GTGdT tPMr6fP/caz/Re4iwQBaqgPTeIr3IzSgEjWDz6NJ6tP3dc5jO2Y+DiFWAkexsg== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1629214653; a=rsa-sha256; cv=none; b=lv18XjbeRsYllw/+tvY4V7kmDzrSh7NVafNsWioxw44XDOKAv1siIn9uaTkuuuVLtR2TZ0 75PpEcm3U+0axYo54icP5LKlNageZDNXGXeCKBEhx2SmdMBwwrdxCpSbsu/PwWax14TqbY cNatrrCMbwa/ws/tZhKc43gkw2GKD++Ot0RqQM8i0cAVA36CacOBvjI9uE0qQGTh3q2uNd vUH6tmAz9XhmVyMnQDCAQXPkt3BWksKpi04NIMwGqAG1/kDuUXJNZSx32PNRiZqpYpxv9w rtQAOp25wNThUXWOFCa4y7gZ8GB9DMguOWMChsM8FsWgV26v3dxwGYDhZZn+Eg== 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: Tue, 17 Aug 2021 15:37:54 -0000 Christian Hopps writes: > I also need to point out that we are only talking about the case > where the implementation doesn=E2=80=99t use a timer to timeout missi= ng > packets. We specifically added text highlighting that > implementations are free to timeout missing packets much earlier if > they so choose. Perhaps we should also highlight this again=3F=3F=20 I do not really see how this timer text helps, or at all related to this discussion: =09=09Implementations that are concerned about memory use when packets are delayed (e.g., when an S= A deletion is delayed), or non-IP-TFS uses of AGGFRAG mode, can of course use timers to drop packets as well. It seems to cover cases where SA is deleted or non-IP-TFS uses of AGGFRAG mode, which are not a concern here. Or non-IP-TFS uses of AGGFRAG mode might be relevant here, but I think the issues are also for IP-TFS uses of AGGFRAG.=20 --=20 kivinen@iki.fi From nobody Tue Aug 17 08:46:58 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE9E3A203A for ; Tue, 17 Aug 2021 08:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOZ1tpKlV4Ik for ; Tue, 17 Aug 2021 08:46:54 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4DB3A2039 for ; Tue, 17 Aug 2021 08:46:54 -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 B370680EA1; Tue, 17 Aug 2021 15:46:53 +0000 (UTC) References: <41C188CD-9B34-4FD9-A9B9-632C335253A4@chopps.org> <24858.42061.118149.546106@fireball.acr.fi> <24858.54291.205079.485517@fireball.acr.fi> <04158312-E6F2-4467-B435-58D77ED7435E@dell.com> <509B58FB-03A1-4C28-BE47-1E4A47478512@chopps.org> <24859.37908.612701.587580@fireball.acr.fi> <9BD66C9D-9E6C-4BEC-A71F-D74B667EA503@chopps.org> <8B9B2CB1-D470-45AD-9C9A-218FB3DBE811@chopps.org> <24859.55228.954532.765168@fireball.acr.fi> User-agent: mu4e 1.5.13; emacs 27.2 From: Christian Hopps To: Tero Kivinen Cc: Christian Hopps , "Koning, Paul" , "ipsec@ietf.org" Date: Tue, 17 Aug 2021 11:44:06 -0400 In-reply-to: <24859.55228.954532.765168@fireball.acr.fi> 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: Tue, 17 Aug 2021 15:46:57 -0000 --=-=-= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Tero Kivinen writes: > Christian Hopps writes: >> I also need to point out that we are only talking about the case >> where the implementation doesn=E2=80=99t use a timer to timeout missing >> packets. We specifically added text highlighting that >> implementations are free to timeout missing packets much earlier if >> they so choose. Perhaps we should also highlight this again?? > > I do not really see how this timer text helps, or at all related to > this discussion: I'm saying we should add new text that mentions the use of this drop timer = to drop missing packets after a short waiting time instead of just waiting = for it to slide out of the reorder window. Then there is no issue to discus= s anymore AFAICT. Thanks, Chris. > > Implementations that are > concerned about memory use when packets are delayed (e.g., when an SA > deletion is delayed), or non-IP-TFS uses of AGGFRAG mode, can of > course use timers to drop packets as well. > > It seems to cover cases where SA is deleted or non-IP-TFS uses of > AGGFRAG mode, which are not a concern here. > > Or non-IP-TFS uses of AGGFRAG mode might be relevant here, but I think > the issues are also for IP-TFS uses of AGGFRAG. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAmEb2eoACgkQLh2DDte4 MCX+hw//Rfdn173Nfq0hJToD83vPqbqXASa4ML0H7R6VVPpSIA3sgDTqPtzDUoB0 KQFURmazT+dOfjj9ZTHFniQgRhxylN0klZ0kodt6QsaD9O6T3mcoF82RExyhpi9r uNFPI4AayreFkV9LD4ZB9X17n3gCew/Sa5H3paPUqeHpi4k/iFAh2nuVtZnG3cWE RKkCj7EbblWbOXXLsvmC4Q1D+rQ8XMQGBST5xBDFuK+hTHkXRSSk1Z4rPohyuyrf Br8DYTu+xjKYUveBZhhk41ssQwfWyiPAbcGB4Jl1SbWUxMO9FOcHXSoKYR8p5sDu 5cpWmylbj6mWbTVjiNOdRzvBWILTW3MRsAAINBsruAJEIcOz2JRejLkbxBguv/sK oo8fFKTh7YytkF5TP6THuGpUxfeJeogLMq3jgmkWfdNwcujVj+39GSt9QJHWcLJr FWPUThdN7INQ8fxJxlrGGMVcdoh8Ol0OMFhTffCrlkoIwGyn+BlZx1BjWD570ZHH C+PGmwYhXBOYo9qabYn3SDKvXJX1/VEW2jExAyiTfpaOTE52kVCj3+qOUEyrYiBq egf0pCeukIulhF64t/aja0fLaP/oQgRRXX9ZnrooLLIXJXVthNpejrPKCXc8/Kst S/ibeEYCYMz/CCk48sciKruEGP2QSxF/EIv/d4TI3hTdv0vYzs4= =Yz7/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 17 09:18:48 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 8894C3A213A for ; Tue, 17 Aug 2021 09:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EP1qLn__MOqD for ; Tue, 17 Aug 2021 09:18:41 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA3A63A213D for ; Tue, 17 Aug 2021 09:18:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 723443898D; Tue, 17 Aug 2021 12:23:43 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MZZODMaVAR_1; Tue, 17 Aug 2021 12:23:38 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id EF07A38983; Tue, 17 Aug 2021 12:23:37 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 60E59407; Tue, 17 Aug 2021 12:18:34 -0400 (EDT) From: Michael Richardson To: Christian Hopps , Tero Kivinen , "Koning\, Paul" , "ipsec\@ietf.org" In-Reply-To: <9BD66C9D-9E6C-4BEC-A71F-D74B667EA503@chopps.org> References: <41C188CD-9B34-4FD9-A9B9-632C335253A4@chopps.org> <24858.42061.118149.546106@fireball.acr.fi> <24858.54291.205079.485517@fireball.acr.fi> <04158312-E6F2-4467-B435-58D77ED7435E@dell.com> <509B58FB-03A1-4C28-BE47-1E4A47478512@chopps.org> <24859.37908.612701.587580@fireball.acr.fi> <9BD66C9D-9E6C-4BEC-A71F-D74B667EA503@chopps.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] 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: Tue, 17 Aug 2021 16:18:47 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Christian Hopps wrote: > In particular why don=E2=80=99t we simply indicate that a lost packet= can > induce a delay of the fixed packet interval times the window size - 1, > and so the widow size should be kept to a minimum, and leave it at > that. Agreed. >> We have approved text from the transport experts now (in addition to >> clearing WG LC). I do not want to open this draft back up for major >> modifications that start talking about new ways to handle packets and >> their affects on the drownstream network etc. This is not our area of >> expertise, and we have already received approval from the experts for >> the text that we have. Let=E2=80=99s stick with the approved text an= d make >> clarifying modifications only. I understand and agree. Maybe clearly pointing at what text is involved would help. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmEb4VoACgkQgItw+93Q 3WW7wwgAoZr/JB+DbLjY+UuAUtKIpNVa6Uyr+H+LxedGDFzPTnsxovs5N9iMIBAb HIjhgdp5MqryoHh1qF1Cb4LUDIFrrE2gCTyMMEMHHf1PepipJoMocI0SAXFtTLY+ 0Rcl4mQYIqH+HI1AmdW7C2QVZMk2JDu9W2Y+yAHu8T+JyTG8uygt0FA031B0M3XX DaVPMb+BgwZ+yfx5IMukYB/bwCGilyUQdkIy0xaf7EhqIqKuN92nqwL6YjS7to44 R42t5Qf3JqhrNTi3VO+4CO1yhY1zSL24i5L6xTn+CzZA0kD3glalIm0xP2H4P7Ck 9GX/awXqCj0KvwmUTjcA1d9lHEb4iA== =JWdO -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 19 13:41:32 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 BAA963A00B2; Thu, 19 Aug 2021 13:41:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yoav Nir via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk Cc: iesg-secretary@ietf.org, ipsec@ietf.org, ipsecme-chairs@ietf.org, ynir.ietf@gmail.com Message-ID: <162940568974.6292.17671505429986597540@ietfa.amsl.com> Date: Thu, 19 Aug 2021 13:41:29 -0700 Archived-At: Subject: [IPsec] Publication has been requested for draft-ietf-ipsecme-ikev2-intermediate-07 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, 19 Aug 2021 20:41:30 -0000 Yoav Nir has requested publication of draft-ietf-ipsecme-ikev2-intermediate-07 as Proposed Standard on behalf of the IPSECME working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-intermediate/ From nobody Fri Aug 20 00:38: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 DE1F23A103F for ; Fri, 20 Aug 2021 00:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=post-quantum-com.20150623.gappssmtp.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 E_s6GvArFevw for ; Fri, 20 Aug 2021 00:38:41 -0700 (PDT) Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) (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 A85603A103E for ; Fri, 20 Aug 2021 00:38:41 -0700 (PDT) Received: by mail-yb1-xb35.google.com with SMTP id q70so1036089ybg.11 for ; Fri, 20 Aug 2021 00:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=post-quantum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5rz5SA1IxuEqjX83t9CWtMW3agox9C5+k1UkS3jPoOM=; b=l4OuJ7ws2zEIC8EUbA9KBkDUfBoTbxGXWi1uYIuUq9vPZmEyomHGoFGV+6UfobjFF+ JQbQe7nYPtPeuecMCgKCO7gCTMOsLkRehE7WH+9pGUoZGFjlrwf+mNCCs/Fp6lJSeULi Rm9DkQzeOHZPmIfoZQknfQXpJD+9JXbjwNSD2A6Emn8xrsqL1IpnW8i8eFeSgKNnh+Tq riAekHibVfo2gxnL7diANY72Q1b0vTTf2vymOxh1vDesvt/LBCGk4Rlkhhenp5sV3eIJ t9BQprEn99m7BNl9vKghJeOZdHJNVmhlDWnTe0ZhrGv50e0DbP5pkHT4GO+ncnwM3e+L oRPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5rz5SA1IxuEqjX83t9CWtMW3agox9C5+k1UkS3jPoOM=; b=r1Eg8OPdWAYYJBKT5ahNpCWXwayO5OZwV+6w1WLHDcCWkLBpGv/qVLAvjA/rnY+grX sXf+pgf/dIkyvo3vpoDa8Iy9gEVXNPcd2MRKe/ovZzac4K2c12cDPFQSE8Mbwv8aPPgH lE2SFv7YOVxf35RBRTtogYZYkV1gakGFskKOM0CzNJ0Qc/DzLn8kkZLPcIVtO/rmpTMV GCaU0LTLA37BcpaFswDaiTaC5JonXJxlFZ0KCcJ2JLToNjVwLgd4fwYiWxWirJTST5uD BnA2rzvYCOTZKLHH3y6pNFLE6xPMbP9pNBqFCMhJB3E3lTKlXOzJLT8CoGttC9tWjP+F 9RQQ== X-Gm-Message-State: AOAM531aPgLzprghZdSgnVW9Agvb0xGvz1ETXlVMl4LOm56/OP21Q9Aq Wakj8q5eM0Bm/hjC5YpcrOgbQq2PnxlSeeK+vvVog1W0Cw9TEsr/7SMnGKpR5nSU6g7J7pI0jU9 bsP677Cq8fsAUsgI= X-Google-Smtp-Source: ABdhPJw6TqQWpUPDTA89/Zk3YYYpz2ggp7yacWWjy9/jvl7Gup+lQi9NmcDYYqa5cv4gPKTPRApGwW1cn3JDRmC8zUU= X-Received: by 2002:a25:a0ce:: with SMTP id i14mr23024222ybm.474.1629445119287; Fri, 20 Aug 2021 00:38:39 -0700 (PDT) MIME-Version: 1.0 References: <24831.15134.45575.357305@fireball.acr.fi> <6bca2d7d-a061-148b-bbdb-1783e72a936@nohats.ca> <1ced01d78558$c3696700$4a3c3500$@gmail.com> <78be2fbb-5efa-826e-b593-1a7194ec34f4@nohats.ca> In-Reply-To: <78be2fbb-5efa-826e-b593-1a7194ec34f4@nohats.ca> From: CJ Tjhai Date: Fri, 20 Aug 2021 08:38:27 +0100 Message-ID: To: Paul Wouters Cc: Valery Smyslov , "ipsec@ietf.org WG" , Tero Kivinen Content-Type: multipart/alternative; boundary="0000000000008436de05c9f8c1f5" 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, 20 Aug 2021 07:38:48 -0000 --0000000000008436de05c9f8c1f5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 16 Aug 2021 at 21:24, Paul Wouters wrote: > On Fri, 30 Jul 2021, Valery Smyslov wrote: > > [ replying as I got prompted by Tero on this regarding WGLC ] > > >> 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 seri= es > >> 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 thei= r > 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. > > I guess this all still feels like a bit of a kludge. I wonder if there > is a way to do this with one new transform type, and an ordered list of > proposals inside. I understand the desire to specify order, but I feel > the current method is fragile and error prone. Eg if one end has > Additional Key Exchange 1 =3D SIKE_P434, Additional Key Exchange 2 =3D > FRODOKEM_640_AES > and the other end has Additional Key Exchange 1 =3D FRODOKEM_640_AES, > Additional Key Exchange 2 =3D SIKE_P434, > where both might not really care which goes first or second. > > I think it would be worth thinking about this problem a bit more. > I think the problem above could be addressed by running a matching algorithm where both peers use the initiator's ordering as the reference. So when the responder receives the Additional Key Exchange proposals, it could run the following matching algorithm: ACCEPTED =3D [] for (i : all initiator AKE proposals) { found =3D no for (r : all responder AKE proposals) { if (r-th responder AKE proposals not been accepted) { selected =3D intersection(i-th initiator AKE proposals, r-th responder AKE proposals)[0] or-else NO_MATCH if (selected !=3D NO_MATCH) { mark r-th responder AKE proposals as accepted ACCEPTED =3D [ACCEPTED selected] found =3D yes break } } } if (found =3D=3D no && NONE not in i-th initiator AKE proposal) { Failure, NO_PROPOSAL_CHOSEN? } } So it will either obtain a list of accepted Additional Key Exchange algorithms or a negotiation failure which will result in NO_PROPOSAL_CHOSEN notification. With the above matching algorithm, the difference in ordering of Additional Key Exchange proposals between initiator and responder does not matter as the responder will try to best match the proposals of the initiator. Of course, further check needs to be run on the initiator site to make sure that the accepted Additional Key Exchange proposals are the supported ones and that there is an accepted proposal for each Additional Key Exchange transform type where NONE is not advertised. If we need to collapse Additional Key Exchange 1, ..., Additional Key Exchange n transform types into one, I think we will still need to have the ability to offer different grouping of proposals. So I am not sure how simpler this could be, but yes, it would be good to have more discussion on this. > > 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. > > Then please say it clearly, instead of implying it. > > >> 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. > > Sure, but it would be best if such a new document would not need to > Updates: this document just for this one little change. So why not: > > - Each IKE_INTERMEDIATE exchange MUST bear exactly one key exchange metho= d. > + All Additional Key Exchanges MUST be in their own Exchange - that is > + these KE's cannot be exchanged via a single IKE message exchange. > > > I also just realised that Addtional Key Exchange is not the best term > for this, as it is very close to Internet Key Exchange and people might > think this is a chain of IKEv2 and something else. Maybe "Additional KE > Exchange" would be better? > > > 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. > > I tried to phrase it above, but I think it can be improved upon further. > > >> So how does an intiiator convey that it deems an additional Key Exchan= ge > >> 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. > > That makes it clearer, but. If each Additional Key Exchange carries a > None, does that mean it these Exchanges can be fully omitted and we are > only doing DH/KE from IKE_SA_INIT ? What if the Additional Key Exchange > 1 contains None, and there is an Additional Key Exchange 2 ? Does it > mean that everything can still be skipped ? > > I'm still not a big fan of the specification this way. I wish we could > find a way to do this in one new transform type and somehow enforcing > an ordered list. > > > > >> If the initiator includes any transform of type n (where > >> n is among Additional Key Exchanges) in the proposal, the respond= er > >> 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 transfo= rm > >> type ? ( eg n=3D6 ??) or a new entry in the Transform Type 4 Key Exch= ange > >> 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". > > Understood. > > >> 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. > > Please please please include some asci art of this exchange in > IKE_SA_INIT. I ensure you that will make it much more easy for a new > reader to understand this. > > Yes, I agree. We will update the draft to include some ASCII art showing the exchanges. > > (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. > > I'm not convinced this is a valid reason to break open the clear state > of CREATE_CHILD_SA and a REKEYed IKE SA. This is really unpleasant for > our state machine. > > >> 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 genera= te > >> 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. > > Again, then why not simply use the MSGID of the corresponding > CREATE_CHILD_SA ? > > >> 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. > > Understood (but see above) > > >> 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. > > Okay. > > >> It is possible that due to some unexpected events (e.g. reboot) t= he > >> 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 alread= y > >> 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? > > I'm lost here too now. But I think however something workds if it saves > state and reboots should not affect the protocol design? > > >> 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 sequenc= e > > after rebooting and restoring last stable IKE SA state. > > Well yes. If the initiator is broken, the connection might fail. I don't > think we need to guard against that. > > >> 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. > > I think this just complicates things too much. We shouldn't have > confused peers or forgetful peers. Just hard fail when something > unexpected happens. assert() for the win :P > > >> 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? > > I can try. > > >> 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 wou= ld > >> 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 i= s, > >> 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", th= en > >> 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. > > so this was again me being confused about the entire mechanism of the > draft. This is why I strongly urge you to add some ascii art about how > these payloads flow (as part of the SA payload) > > >> 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. > > Okay. > > >> 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 rejecte= d > >> 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. > > Okay. > The subsequent paragraphs in the Appendix also state that it is possible to protect against this attack with some configuration/policy. Best regards CJ > > >> 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 :-) > > While we might be in agreement, we are in disagreement on why the other > approach was discarded :) So the real question is, should it be > considered? > > I do think that this document needs some more work to clarify things, > and I would really like to see more people reviewing this document as > well. > > I would also like to see a discusion of a "simpler" design that would > not use 4 Transform Type's, but only 1, and see if that would be > "simpler" (simpler in quotes twice because i can't evaluate yet > without such discussion which would be the simpler solution. > > Paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --=20 PQ Solutions Limited (trading as =E2=80=98Post-Quantum=E2=80=99) is a priva= te limited=20 company incorporated in England and Wales with=C2=A0registered number 06808= 505. =C2=A0 This email is meant only for the intended recipient. If you have received= =20 this email in error, any review, use, dissemination,=C2=A0distribution, or= =20 copying of this email is strictly prohibited. Please notify us immediately= =20 of the error by return email and please=C2=A0delete this message from your= =20 system. Thank you in advance for your cooperation. For more information=20 about Post-Quantum, please visit www.post-quantum.com=20 . In the course of our business relationship,=20 we may collect, store and transfer information about you. Please see our=20 privacy=C2=A0notice at www.post-quantum.com/privacy-notice=20 to learn about how we use this= =20 information. --0000000000008436de05c9f8c1f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, 16 Aug 2021 at 2= 1:24, Paul Wouters <paul.wouters=3D40aiven.io@dmarc.ietf.org> wrote:
On Fri, 30 Jul 2021, Val= ery Smyslov wrote:

[ replying as I got prompted by Tero on this regarding WGLC ]

>> 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. >>
>>=C2=A0 =C2=A0 =C2=A0 Key exchange methods negotiated via Transform = Type 4 MUST always take
>>=C2=A0 =C2=A0 =C2=A0 place in the IKE_SA_INIT exchange.=C2=A0 Addit= ional key exchanges
>>=C2=A0 =C2=A0 =C2=A0 negotiated via newly defined transforms MUST t= ake place in a series
>>=C2=A0 =C2=A0 =C2=A0 of IKE_INTERMEDIATE exchanges, in an order of = the values of their
>>=C2=A0 =C2=A0 =C2=A0 transform types, so that key exchange negotiat= ed using Transform Type
>>=C2=A0 =C2=A0 =C2=A0 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 negotiate= d,
> the order in which they will take place is defined by the order
> of assigned Transform Types (which will correspond to the order of the= ir 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,<= br> > 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.

I guess this all still feels like a bit of a kludge. I wonder if there
is a way to do this with one new transform type, and an ordered list of
proposals inside. I understand the desire to specify order, but I feel
the current method is fragile and error prone. Eg if one end has
Additional Key Exchange 1 =3D SIKE_P434, Additional Key Exchange 2 =3D FROD= OKEM_640_AES
and the other end has Additional Key Exchange 1 =3D FRODOKEM_640_AES, Addit= ional Key Exchange 2 =3D SIKE_P434,
where both might not really care which goes first or second.

I think it would be worth thinking about this problem a bit more.

I think the problem above could be addressed by = running a matching algorithm where both peers use the initiator's order= ing as the reference. So when the responder receives the Additional Key Exc= hange proposals, it could run the following matching algorithm:
<= br>
=C2=A0 ACCEPTED =3D []
=C2=A0 for (i : all initiator = AKE proposals) {
=C2=A0 =C2=A0 found =3D no
=C2=A0 =C2=A0 for (r : al= l responder AKE proposals) {
=C2=A0 =C2=A0 =C2=A0 if (r-th responder AKE= proposals not been accepted) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 selected =3D= intersection(i-th initiator AKE proposals, r-th responder AKE proposals)[0= ] or-else NO_MATCH
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (selected !=3D NO_MATC= H) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mark r-th responder AKE proposal= s as accepted
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ACCEPTED =3D [ACCEPTED = selected]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 found =3D yes
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 break
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 = =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 if (found =3D=3D no &am= p;& =C2=A0NONE not in i-th initiator AKE proposal) {
=C2=A0 =C2=A0 = =C2=A0 Failure, NO_PROPOSAL_CHOSEN?
=C2=A0 =C2=A0 }
=C2=A0 }
So it will either obt= ain a list of accepted Additional Key Exchange algorithms or a negotiation = failure which will result in NO_PROPOSAL_CHOSEN notification. With the abov= e matching algorithm, the difference in ordering of Additional Key Exchange= proposals between initiator and responder does not matter as the responder= will try to best match the proposals of the initiator. Of course,=C2=A0fur= ther check needs to be run on the initiator site to make sure that the acce= pted Additional Key Exchange proposals are the supported ones and that ther= e is an accepted proposal for each Additional Key Exchange transform type w= here NONE is not advertised.

If we need to collaps= e Additional Key Exchange 1, ..., Additional Key Exchange n transform types= into one, I think we will still need to have the ability to offer differen= t grouping of proposals. So I am not sure how simpler this could be, but ye= s, it would be good to have more discussion on this.


> 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.

Then please say it clearly, instead of implying it.

>>=C2=A0 =C2=A0 =C2=A0 Each IKE_INTERMEDIATE exchange MUST bear exact= ly 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 th= at?
>
> We didn't consider such exotic key exchange methods and, I think,<= br> > if they appear, they will deserve a separate document.

Sure, but it would be best if such a new document would not need to
Updates: this document just for this one little change. So why not:

- Each IKE_INTERMEDIATE exchange MUST bear exactly one key exchange method.=
+ All Additional Key Exchanges MUST be in their own Exchange - that is
+ these KE's cannot be exchanged via a single IKE message exchange.


I also just realised that Addtional Key Exchange is not the best term
for this, as it is very close to Internet Key Exchange and people might
think this is a chain of IKEv2 and something else. Maybe "Additional K= E
Exchange" would be better?

> 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.

I tried to phrase it above, but I think it can be improved upon further.
>> So how does an intiiator convey that it deems an additional Key Ex= change
>> to be mandatory?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0If the initiator includes "Additional K= ey Exchange N" transform,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0then the responder MUST choose a single meth= od from
>=C2=A0 =C2=A0 =C2=A0 =C2=A0those included in this transform. If the lis= t of included
>=C2=A0 =C2=A0 =C2=A0 =C2=A0methods doesn't contain NONE, then the r= esponder
>=C2=A0 =C2=A0 =C2=A0 =C2=A0have to choose one of them, so performing th= is KE
>=C2=A0 =C2=A0 =C2=A0 =C2=A0method is mandatory. To make it optional the= initiator
>=C2=A0 =C2=A0 =C2=A0 =C2=A0includes NONE among other methods. This allo= ws
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the responder to select NONE and thus to ski= p doing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0this additional KE.

That makes it clearer, but. If each Additional Key Exchange carries a
None, does that mean it these Exchanges can be fully omitted and we are
only doing DH/KE from IKE_SA_INIT ? What if the Additional Key Exchange
1 contains None, and there is an Additional Key Exchange 2 ? Does it
mean that everything can still be skipped ?

I'm still not a big fan of the specification this way. I wish we could<= br> find a way to do this in one new transform type and somehow enforcing
an ordered list.



>>=C2=A0 =C2=A0 =C2=A0 If the initiator includes any transform of typ= e n (where
>>=C2=A0 =C2=A0 =C2=A0 n is among Additional Key Exchanges) in the pr= oposal, the responder
>>=C2=A0 =C2=A0 =C2=A0 MUST select one of the algorithms proposed usi= ng this type.=C2=A0 A
>>=C2=A0 =C2=A0 =C2=A0 transform ID NONE may be added to those transf= orm types which contain
>>=C2=A0 =C2=A0 =C2=A0 key exchange methods that the initiator believ= es are optional.
>>
>> And so I again do not understand this. What is "n" here?= a new transform
>> type ? ( eg n=3D6 ??)=C2=A0 or a new entry in the Transform Type 4= Key Exchange
>> registry?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0n here is new Transform Type. We define &quo= t;Additional Key Exchange 1",
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"Additional Key Exchange 2", "= ;Additional Key Exchange 3" ...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0up to "Additional Key Exchange 7".=

Understood.

>> At his point, the Additional Key Exchange is introduced, and I am<= br> >> beginning to understand things. This should really be explained be= fore
>> the text I pointed at above to make any sense to the reader. And s= ee
>> below on placing "Additional Key Exchanges" into the &qu= ot;Key Exchanges"
>> Registry.
>
> Actually, the new transforms are introduced in 3.2.1, but I see your p= oint
> and probably we should add more clarifications before this section.
Please please please include some asci art of this exchange in
IKE_SA_INIT. I ensure you that will make it much more easy for a new
reader to understand this.


Yes, I agree. We will update the = draft to include some ASCII art showing the exchanges.
=C2=A0
=C2=A0
> (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 exc= hanges. I
>> personally would prefer that a different exchange than CREATE_CHIL= D_SA
>> is used if the completion of such an exchange does not lead to a f= ully
>> rekeyed state. This use of completing a CREATE_CHILD_SA and being = in a
>> state that is not "rekeyed" or "failed" compli= cates the state machine.
>
> That's true. However, there is a tradeoff here. If you defined a n= ew 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.

I'm not convinced this is a valid reason to break open the clear state<= br> of CREATE_CHILD_SA and a REKEYed IKE SA. This is really unpleasant for
our state machine.

>>=C2=A0 =C2=A0 =C2=A0 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 ge= nerate
>> 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.

Again, then why not simply use the MSGID of the corresponding CREATE_CHILD_= SA ?

>> Below is an example of three additional key exchanges.
>>
>>=C2=A0 =C2=A0 =C2=A0Initiator=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=A0 =C2=A0Responder=
>>=C2=A0 =C2=A0 =C2=A0-----------------------------------------------= ----------------------
>>=C2=A0 =C2=A0 =C2=A0HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi} --> >>=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=A0 =C2=A0 =C2=A0<--=C2=A0 HDR(CREATE_CHILD_= SA), SK {SA, Nr, KEr,
>>=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=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 N= (ADDITIONAL_KEY_EXCHANGE)(link1)}
>>
>>
>> Why does the initiator not start out with a N(ADDITIONAL_KEY_EXCHA= NGE) ?
>> 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 CREA= TE_CHILD_SA.

Understood (but see above)

>> It has given no indication it might be mandatory from the initiato= r's point of view.
>
> You are right, this must be clarified in the draft.

Okay.

>>=C2=A0 =C2=A0 =C2=A0 It is possible that due to some unexpected eve= nts (e.g. reboot) the
>>=C2=A0 =C2=A0 =C2=A0 initiator could forget that it is in the proce= ss of performing
>>=C2=A0 =C2=A0 =C2=A0 additional key exchanges and never starts next= IKE_FOLLOWUP_KE
>>=C2=A0 =C2=A0 =C2=A0 exchanges.=C2=A0 The responder MUST handle thi= s situation gracefully
>>
>> And wouldn't that solve this weird state issue if the initiato= r 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?

I'm lost here too now. But I think however something workds if it saves=
state and reboots should not affect the protocol design?

>> 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 sequen= ce
> after rebooting and restoring last stable IKE SA state.

Well yes. If the initiator is broken, the connection might fail. I don'= t
think we need to guard against that.

>>=C2=A0 =C2=A0 =C2=A0 it MUST send back a new error type notificatio= n STATE_NOT_FOUND.
>>=C2=A0 =C2=A0 =C2=A0 This is a non-fatal error notification
>>=C2=A0 =C2=A0 =C2=A0 [...]
>>=C2=A0 =C2=A0 =C2=A0 If the initiator receives this notification in=
>>=C2=A0 =C2=A0 =C2=A0 response to IKE_FOLLOWUP_KE exchange performin= g additional key
>>=C2=A0 =C2=A0 =C2=A0 exchange, it MUST cancel this exchange and MUS= T treat the whole
>>=C2=A0 =C2=A0 =C2=A0 series of exchanges started from the CREATE_CH= ILD_SA exchange as
>>=C2=A0 =C2=A0 =C2=A0 failed.
>>
>> So why use a non-fatal error notification that leads to a guarante= ed failure ?
>
> Because the failure may be recoverable - just start new CREATE_CHILD_S= A
> 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.

I think this just complicates things too much. We shouldn't have
confused peers or forgetful peers. Just hard fail when something
unexpected happens. assert() for the win :P

>> Note there seems to be a notion of AKE's having continuous sta= te, as
>> opposed to (EC)DH where you start a new state with the rekey excha= nge.
>> Perhaps this should be clarified at the beginning of the document?=
>
> Can you please provide text candidate?

I can try.

>>=C2=A0 =C2=A0This document adds the following Transform Types to th= e "Transform
>>=C2=A0 =C2=A0 =C2=A0Type Values" registry:
>>
>>=C2=A0 =C2=A0 =C2=A0Type=C2=A0 =C2=A0 =C2=A0Description=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Used In
>>=C2=A0 =C2=A0 =C2=A0-----------------------------------------------= ------------------
>>=C2=A0 =C2=A0 =C2=A0<TBA>=C2=A0 =C2=A0 Additional Key Exchang= e 1=C2=A0 =C2=A0 =C2=A0(optional in IKE, AH, ESP)
>>=C2=A0 =C2=A0 =C2=A0<TBA>=C2=A0 =C2=A0 Additional Key Exchang= e 2=C2=A0 =C2=A0 =C2=A0(optional in IKE, AH, ESP)
>>=C2=A0 =C2=A0 =C2=A0<TBA>=C2=A0 =C2=A0 Additional Key Exchang= e 3=C2=A0 =C2=A0 =C2=A0(optional in IKE, AH, ESP)
>>=C2=A0 =C2=A0 =C2=A0<TBA>=C2=A0 =C2=A0 Additional Key Exchang= e 4=C2=A0 =C2=A0 =C2=A0(optional in IKE, AH, ESP)
>>
>>
>> Why are the descriptions referring to "additional" key e= xchange? I would
>> assume the registry is just a list of Key Exchange types, and whet= her
>> one of these is "additional" or not depends on its use i= n IKE ? That is,
>> one of the Key Exchanges that today is "additional" migh= t 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<= br> > are always performed in addition to KE method, negotiated via Transfor= m Type 4.

so this was again me being confused about the entire mechanism of the
draft. This is why I strongly urge you to add some ascii art about how
these payloads flow (as part of the SA payload)

>>= =C2=A0 =C2=A0 =C2=A0 the key lengths of these
>>=C2=A0 =C2=A0 =C2=A0 transforms SHALL be at least 256 bits long in = order to provide
>>=C2=A0 =C2=A0 =C2=A0 sufficient resistance to quantum attacks.
>>
>> I would use MUST instead of SHALL.
>
> OK.
>
>>=C2=A0 =C2=A0 =C2=A0 The main focus of this document is to prevent = a passive attacker
>>=C2=A0 =C2=A0 =C2=A0 performing a "harvest and decrypt" a= ttack.=C2=A0 In other words, an
>>=C2=A0 =C2=A0 =C2=A0 attacker that records messages exchanges today= and proceeds to
>>=C2=A0 =C2=A0 =C2=A0 decrypt them once he owns a quantum computer.= =C2=A0 This attack is
>>=C2=A0 =C2=A0 =C2=A0 prevented due to the hybrid nature of the key = exchange.=C2=A0 Other
>>=C2=A0 =C2=A0 =C2=A0 attacks involving an active attacker using a q= uantum-computer are not
>>=C2=A0 =C2=A0 =C2=A0 completely solved by this document.=C2=A0 This= is for two reasons.
>>
>> I think this part and the text right underneath this belongs in th= e
>> Introduction more than it belongs in the Security Considerations >> section.
>
> This probably makes sence. I'll discuss this with my co-authors.
Okay.

>>=C2=A0 =C2=A0 =C2=A0 Unfortunately, this design is susceptible to t= he following
>>=C2=A0 =C2=A0 =C2=A0 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 rej= ected
>> KE value from the previous response, so that this attack would be<= br> >> 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.
Okay.

The subsequent paragraphs in the = Appendix also state that it is possible to protect against this attack with= some configuration/policy.

Best regards
CJ
=C2=A0

>>=C2=A0 =C2=A0 =C2=A0 We discarded this approach because we believe = that the working
>>=C2=A0 =C2=A0 =C2=A0 group may not be happy using the RESERVED fiel= d to change the
>>=C2=A0 =C2=A0 =C2=A0 format of a packet and that implementers may n= ot like the
>>=C2=A0 =C2=A0 =C2=A0 complexity added from checking the fragmentati= on flag in each
>>=C2=A0 =C2=A0 =C2=A0 received payload.
>>
>> I think that is exactly why we have RESERVED fields. As implemente= r, I
>> don't think that this would have been too complex. But I think= using
>> INTERMEDIATE is fine, especially if multiple solutions can use thi= s
>> 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 :-)

While we might be in agreement, we are in disagreement on why the other
approach was discarded :) So the real question is, should it be
considered?

I do think that this document needs some more work to clarify things,
and I would really like to see more people reviewing this document as
well.

I would also like to see a discusion of a "simpler" design that w= ould
not use 4 Transform Type's, but only 1, and see if that would be
"simpler" (simpler in quotes twice because i can't evaluate y= et
without such discussion which would be the simpler solution.

Paul

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

<= /div>
PQ Solutions Limited (trading as =E2=80=98Post-Quantum=E2=80=99) = is a private limited company incorporated in England and Wales with=C2=A0registered number 06808505.
=C2=A0
This= email is meant only for the intended recipient. If you have received this = email in error, any review, use, dissemination,=C2=A0distribution,= or copying of this email is strictly prohibited. Please notify us immediat= ely of the error by return email and please=C2=A0delete this message from= your system. Thank you in advance for your cooperation.
<= span style=3D"font-size:13px;font-family:Arial,Helvetica,sans-serif">
For more information about Post-Quantum, please visit www.post-quantum.com.
--0000000000008436de05c9f8c1f5-- From nobody Mon Aug 23 06:47:37 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 211AC3A198B for ; Mon, 23 Aug 2021 06:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tM_9pCdpahfb for ; Mon, 23 Aug 2021 06:47:32 -0700 (PDT) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBB853A1991 for ; Mon, 23 Aug 2021 06:47:31 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id v20-20020a1cf714000000b002e71f4d2026so5468wmh.1 for ; Mon, 23 Aug 2021 06:47:31 -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=7fh+kw9FEkedn4gYNEBVkunm9lxU8wRirJaKxdbQmAY=; b=P7RXWK8p97g+pd7LZWju98f9yAi9dYSr1W2fuRD39aAvtSFRMBlDJnCC8rtVaGjlUr 4mrkizdDhgpPzL50BPKDprLafd/hbbT/ve/qVizreV4wXhwxTWbI41K4vf7aYwGteBru IgQlOImIj22JKyzY3FzDz63u8eqX0ijr5cFVZRHjF1H62tPwztmyxmOwzElhA6GEVgzo WjATRke51qn1rcjn6LX070WpJaK9pJOzq63iPlkgY1B2LA/Ht6sMAvncUM9I4ArPgSv1 xgXnLiaDcjyod64hlwZtqlWt1G+r8DJBvd4VXpGsBZQEJqzfzyvGp7ZrTi6jwTsM1A5w ellQ== 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=7fh+kw9FEkedn4gYNEBVkunm9lxU8wRirJaKxdbQmAY=; b=qx7Z4hY1FWWenyQA0fkhonnyR48GPbPmykQcwVTGpbOUsFV1M9IYRiLAC3NdlN7aKL h4EGqPcUB2+FRYYWQ8m6gd25+ppRwCZRL1OGgU9KXBXEVWHrCUQyaOb598POj6fFDaJc Nhb4U/se3b13ZiMgoxg78Deu1ZkKL4boxZyAuhdCpNoKaipunc704s3VexoRZ21UDXIV Ev7mijAwXzvd7uuPmhmT8NjtU4OJEmo2QVHv3us2ZbS/rQTRdYfgEtGdyIRyR1RTjtv/ G+sOeSqI4UyrBEyEKyBUR+HxfPScLxq2kHrdeLADsHT+VV8C4OPAt/3hsCyTbQfywjMv qFDA== X-Gm-Message-State: AOAM5309/XKBq7tiTSnUQrBiQrjQ9FjUy1AkdJt/Ok9ZHoF+6hF5ym7i DH5liZ/yUKgqf/xo13xQgMyJSpQ9dks= X-Google-Smtp-Source: ABdhPJyhQCq4hAJBs/uUmLX3WQHq7aZ9boQEO69GqDKTKKzE0JeMvMTfX1hmzBl6tLrrv9QUCVIstw== X-Received: by 2002:a1c:19c1:: with SMTP id 184mr16730550wmz.98.1629726449560; Mon, 23 Aug 2021 06:47:29 -0700 (PDT) Received: from buildpc ([93.188.44.204]) by smtp.gmail.com with ESMTPSA id b13sm15198615wrf.86.2021.08.23.06.47.28 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Aug 2021 06:47:28 -0700 (PDT) From: "Valery Smyslov" To: "'Paul Wouters'" Cc: "'Paul Wouters'" , "'Tero Kivinen'" , References: <24831.15134.45575.357305@fireball.acr.fi> <6bca2d7d-a061-148b-bbdb-1783e72a936@nohats.ca> <1ced01d78558$c3696700$4a3c3500$@gmail.com> <78be2fbb-5efa-826e-b593-1a7194ec34f4@nohats.ca> In-Reply-To: <78be2fbb-5efa-826e-b593-1a7194ec34f4@nohats.ca> Date: Mon, 23 Aug 2021 16:47:27 +0300 Message-ID: <2b6c01d79825$6a260f10$3e722d30$@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+n6JMQIHkjKzAnzzvGMB9QgniKtXzVEA 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: Mon, 23 Aug 2021 13:47:35 -0000 Hi Paul, > On Fri, 30 Jul 2021, Valery Smyslov wrote: > > [ replying as I got prompted by Tero on this regarding WGLC ] > > >> 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. > > I guess this all still feels like a bit of a kludge. I wonder if there > is a way to do this with one new transform type, and an ordered list of > proposals inside. Currently in IKEv2 a single transform specifies a single algorithm. If initiator wants to propose several algorithms of one type as a choice, it includes in a proposal several transforms. Do you suggest to change this logic, so that a single transform contains a list of of possible algorithms? It would be quit a major change to IKEv2 negotiation mechanism and in my opinion would lead to more complexity (e.g. how you associate attributes with algorithms in this case?). Or am I missing your point? I understand the desire to specify order, but I feel > the current method is fragile and error prone. Eg if one end has > Additional Key Exchange 1 = SIKE_P434, Additional Key Exchange 2 = FRODOKEM_640_AES > and the other end has Additional Key Exchange 1 = FRODOKEM_640_AES, Additional Key Exchange 2 = > SIKE_P434, > where both might not really care which goes first or second. In your example both initiator and responder do care about the order. That's why they cannot negotiate an order appropriate for both. If they don't care then the policy on both ends would be: Additional Key Exchange 1 = SIKE_P434 or FRODOKEM_640_AES, Additional Key Exchange 2 = SIKE_P434 or FRODOKEM_640_AES In this case they either end up with SIKE_P434 + FRODOKEM_640_AES or FRODOKEM_640_AES + SIKE_P434 Note, that the draft prohibits negotiation the same algorithm in different additional key exchanges, so they cannot end up with SIKE_P434 + SIKE_P434 or FRODOKEM_640_AES + FRODOKEM_640_AES. > I think it would be worth thinking about this problem a bit more. If you have better proposals in mind we'll be happy to consider them. > > 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. > > Then please say it clearly, instead of implying it. OK. > >> 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. > > Sure, but it would be best if such a new document would not need to > Updates: this document just for this one little change. So why not: > > - Each IKE_INTERMEDIATE exchange MUST bear exactly one key exchange method. > + All Additional Key Exchanges MUST be in their own Exchange - that is > + these KE's cannot be exchanged via a single IKE message exchange. To my (non-native) eye this looks more difficult to understand. We'll think if some more simple text with similar meaning can be crafted. > I also just realised that Addtional Key Exchange is not the best term > for this, as it is very close to Internet Key Exchange and people might > think this is a chain of IKEv2 and something else. Maybe "Additional KE > Exchange" would be better? I got your point, but I don't think this possible confusion is real enough to be worry about. In addition, if in your proposal the acronym KE is expanded, then we get awkward "Additional Key Exchange Exchange"... That said, I agree that the term "Key Exchange" (with or without "Additional") is a bit inaccurate. It's OK for DH or ECDH, but for example in PQ world most current methods are in fact KEMs. Probably Key Determination is better? But then we need to rename KE payload to KD payload and so on... > > 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. > > I tried to phrase it above, but I think it can be improved upon further. I hope so. > >> 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. > > That makes it clearer, but. If each Additional Key Exchange carries a > None, does that mean it these Exchanges can be fully omitted and we are > only doing DH/KE from IKE_SA_INIT ? Yes. > What if the Additional Key Exchange > 1 contains None, and there is an Additional Key Exchange 2 ? Does it > mean that everything can still be skipped ? Then Additional Key Exchange 1 is omitted, but Additional Key Exchange 2 is not. So, the sequence of exchanges is: IKE_SA_INIT IKE_INTERMEDIATE (corresponding to KE method from Additional Key Exchange 2 transform) IKE_AUTH > I'm still not a big fan of the specification this way. I wish we could > find a way to do this in one new transform type and somehow enforcing > an ordered list. Please, see above. I also want to say that the current draft makes no changes to IKEv2 code performing algorithms negotiation, and this this code is already complex enough, so I really don't want to make it more complex by changing the format of Transorm (as you seem to suggest). > >> 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". > > Understood. > > >> 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. > > Please please please include some asci art of this exchange in > IKE_SA_INIT. I ensure you that will make it much more easy for a new > reader to understand this. Will do. > > (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. > > I'm not convinced this is a valid reason to break open the clear state > of CREATE_CHILD_SA and a REKEYed IKE SA. This is really unpleasant for > our state machine. Well, your state machine must already handle similar situations, when a single CREATE_CHILD_SA exchange is insufficient to perform a rekey or creating a new Child SA. As an example - if you receive TEMPORARY_FAILURE notification, then you need to restart the exchange after some time. So you have to create some state and remember to re-initiate the CREATE_CHILD_SA exchange. I agree, that it's a bit simpler, then IKE_FOLLOWUP_KE, but very similar. And I still think that performance considerations and message size are very valid in PQ world, so performing several key exchanges one by one is more attractive. > >> 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. > > Again, then why not simply use the MSGID of the corresponding CREATE_CHILD_SA ? This data is only meaningful to responder, so we don't mandate what to put there. Message ID is a good choice, but again it's up to responder. It's like cookie, which is only meaningful to responder. RFC 7296 doesn't mandate how cookie is calculated, it only provides an example. We can add a few words that e.g. using Message ID may be appropriate, but is not mandated. > >> 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. > > Understood (but see above) > > >> 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. > > Okay. > > >> 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? > > I'm lost here too now. But I think however something workds if it saves > state and reboots should not affect the protocol design? I'm not sure. Do you constantly save all active IKE SAs to non-volatile memory so that after reboot they all are restored? I don't think it's always practical and possible. The common approach is that after reboot you completely forget all your SAs and start recreating them from scratch (oh, that's what INITIAL_CONTACT notify for). Consider another example. If initiator starts IKE_SA_INIT, completes it, but then suddenly crashes, so that it never starts IKE_AUTH - should the responder handle this situation? Note, that the half-baked SA is already created on the responder and the state for it is allocated. Or the network outage happens right after the IKE_SA_INIT is completed. Then the initiator will start IKE_AUTH, but eventually fails and clears its SA state, but the responder is unaware of initiator's attempts and unless some measures are taken will keep half-baked SA waiting for IKE_AUTH. So, the responder must clear this state if it sees no IKE_AUTH request message within some time period. Here we have very similar situation, the only difference is that instead IKE_SA_INIT and IKE_AUTH we have CREATE_CHILD_SA and IKE_FOLLOWUP_KE. > >> 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. > > Well yes. If the initiator is broken, the connection might fail. I don't > think we need to guard against that. The initiator isn't broken. And we need to guard. Please see above. > >> 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. > > I think this just complicates things too much. We shouldn't have > confused peers or forgetful peers. Just hard fail when something > unexpected happens. assert() for the win :P It's not only about forgetful peers, it's also about network connectivity. if there is some temporary network outage when the initiator starts IKE_FOLLOWUP_KE, so that the responder deletes state associated with CREATE_CHILD_SA, then it makes sense to retry the whole sequence of exchanges. Again, RFC 7296 already has very similar notification - TEMPORARY_FAILURE and you have to handle it anyway. > >> 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? > > I can try. OK. > >> 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. > > so this was again me being confused about the entire mechanism of the > draft. This is why I strongly urge you to add some ascii art about how > these payloads flow (as part of the SA payload) Will do. > >> 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. > > Okay. > > >> 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. > > Okay. > > >> 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 :-) > > While we might be in agreement, we are in disagreement on why the other > approach was discarded :) So the real question is, should it be > considered? It was discussed on the mailing list in length. There were several alternate approaches. What about this particular para - it discusses an alternative approach when all KE payloads are sent in IKE_SA_INIT. Then we have a problem with IP fragmentation of this message and this piece of text discusses a way to fragment IKE_SA_INIT message. It would introduce an alternative fragmentation mechanism, because RFC 7383 can only be used after IKE_SA_INIT is completed. Then it would open a lot of problems that were discussed when we worked on RFC 7383. Overall, the approach of re-using an existing IKE Fragmentation mechanism was taken (via IKE_INTERMEDIATE). > I do think that this document needs some more work to clarify things, > and I would really like to see more people reviewing this document as > well. > > I would also like to see a discusion of a "simpler" design that would > not use 4 Transform Type's, but only 1, and see if that would be > "simpler" (simpler in quotes twice because i can't evaluate yet > without such discussion which would be the simpler solution. If you have this design in mind, please share it. I can only guess how you are going to perform the negotiation with only one new transform type, and my guess can be wrong. Regards, Valery. > Paul From nobody Wed Aug 25 07:08: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 4B8C83A0E3F for ; Wed, 25 Aug 2021 07:08:39 -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 NbhzTEDI-o1l for ; Wed, 25 Aug 2021 07:08:33 -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 ED9A03A0E13 for ; Wed, 25 Aug 2021 07:08:32 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id g138so15073003wmg.4 for ; Wed, 25 Aug 2021 07:08:32 -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=+1Spej/0Htdy61MJJwEv6pRaNDDzB47BoFivW2XKrJw=; b=hmzrsuY/XkbATfNF5JXaThKr1Tcb6Vnn25F9yIIzNKQ6Mr7/SUSGy72ul+na8KjfR4 9mvphhOQa54m7cIlgC9yWFzSehMsEG2EwCiA9UsGwJT1RHeF/sdeCQP3GSuCK258Y/KI id3dKRfe2sICZx9UP3Nl41AE1zHdINMciflPpR0J7Wzftvz3N4HT47Tmf0RJw122nLaQ tYH0oGg1esFDEmEat7F8dqZ4n6KxAM5NM+Kp5xUXD/GJXiX5OCBX6LaTaTJz/shVTOiS 1tFx9IBrgoQI7HnafHkl7ZN1tMKAn9IHAo4JjweA23uS2/MaxdWbvM392RGZqcfQhJy8 nQDA== 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=+1Spej/0Htdy61MJJwEv6pRaNDDzB47BoFivW2XKrJw=; b=Q61ZS5/fpnxAXnNHb4d15TY+ur5pgXT3GNoi61yqS7jf1qTXRW1AOFWAXXqp7+uBp+ oISHlL7qWR5uT/aj6Cog0UzGx97j181pIb40k60lUG+AF0wAPFGvaOK3Ep9Jl+4qtPEb tH0HkgWKwOUx0Zxis6GqE7BdW86bhkCnXyCHn79nPFGGIhYwG7JjbNlRek3BQw9LQYVF n9L1x5mmpZR0XRmZnkf/7YBNPXWzZ6QSSY66F8Wer01+BmYAMojcjAJRPFQ7bZ+MZ5+h h++V9oXqOQ3//lFzIyTsAXfsqPy8f6cokgCcPGo+DOU+FsVAIEEwvXXHaqzI7+FY9mdR coXw== X-Gm-Message-State: AOAM530r8qwirW/upx62a8G2iifOHZcVGwls2pGKMHv7dsY2Qg7ITjee ZL2lrbmxv3OQC8llRdRTlfxcWhoMWBQ= X-Google-Smtp-Source: ABdhPJz8Oxxvvn0vi8+ign+MQ8S0EyH7XqXPBOMgCCsuMD/eUR8sFBM8yB+oSZsYCrTQVQhurpO4iQ== X-Received: by 2002:a7b:c30f:: with SMTP id k15mr9602560wmj.128.1629900510087; Wed, 25 Aug 2021 07:08:30 -0700 (PDT) Received: from buildpc ([93.188.44.204]) by smtp.gmail.com with ESMTPSA id n14sm14656wrx.10.2021.08.25.07.08.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Aug 2021 07:08:29 -0700 (PDT) From: "Valery Smyslov" To: "'Tero Kivinen'" , References: <24831.15082.263253.443690@fireball.acr.fi> In-Reply-To: <24831.15082.263253.443690@fireball.acr.fi> Date: Wed, 25 Aug 2021 17:08:30 +0300 Message-ID: <2d1501d799ba$af76bc40$0e6434c0$@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: AQKYNO/A1f9S/Q/00+U6x9xSlcVzm6oC/VYA Content-Language: ru 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, 25 Aug 2021 14:08:46 -0000 Hi, sorry for being late, the GGLC is already over, but I was really busy to review the draft before. I have few comments. 1. Section 1.2. The last para is erroneous here, since the immediately following the first para of Section 1.3 states exactly the same with more details. Either remove it or rephrase and move to 1.3 (e.g. to keep provided example). 2. Section 2.2. If the TS_SECLABEL is present in a TSi/TSr, at least one Traffic Selector of type TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE MUST also be present in that TSi/TSr. I think this requirement was already spelled out in more generic form in 1.3. Why it is repeated here? 3. Section 2.2 A zero length Security Label MUST NOT be used. If a received TS payload contains a TS_TYPE of TS_SECLABEL with a zero length Security Label, that specific Traffic Selector MUST be ignored. If no other Traffic Selector of TS_TYPE TS_SECLABEL can be selected, a TS_UNACCEPTABLE Error Notify message MUST be returned. A zero length Security Label MUST NOT be interpreted as a wildcard security label. I wonder why zero-length TS_SECLABEL cannot be used to represent "no security label"? This would significantly simplify negotiation when using security labels are optional for initiator. Currently it is proposed that initiator performs two attempts to establish Child SA in this case - with and without TS_SECLABEL. If zero-length TS_SECLABEL meant "no security label", then a single CREATE_CHILD_SA would be sufficient. It would also simplify the IKE state machine for this case. Are there any reasons I'm not aware of? 4. Section 2.2 If multiple Security Labels are allowed for a given IP protocol, start and end address/port match, multiple TS_SECLABEL can be included in a TS payload. This sentence is unclear for me. If the initiator includes multiple TS_SECLABEL, does it mean that the responder must select exactly one of them or not? If yes, then can you please clarify, that the presence of multiple TS_SECLABEL means that selection any of them is acceptable for the initiator. 5. Section 2.2: What is "TS_set", which is mentioned twice in the last para? This acronym was never used before in the dicument. 6. Section 3. Each TS payload (TSi and TSr) MUST contain at least one TS_TYPE of TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE. This is repeated for the third time in the document. Can you please keep the only instance of this requirement? 7. Section 3. A responder MUST create its TS response by selecting one of each TS_TYPE present in the offered TS by the initiator. If it cannot select one of each TS_TYPE, it MUST return a TS_UNACCEPTABLE Error Notify payload. and later Some TS_TYPE's support narrowing, where the responder is allowed to select a subset of the original TS. Narrowing MUST NOT result in an empty selector for that TS_TYPE. This is wrong with regard to TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE. The responder may return any subset of TSs with TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE. E.g, if the initiator included 5 TSs with TS_IPV4_ADDR_RANGE and 3 with TS_IPV6_ADDR_RANGE, then the responder is free to return (just as example) only 2 TS_IPV4_ADDR_RANGE and no TS_IPV6_ADDR_RANGE, and all of them may have different content (due to narrowing). I think this paras must be rephrased more accurately. 8. Section 3.2: It would be unlikely that the traffic for TSi and TSr would have a different Security Label, but this specification does allow this to be specified. Can you please provide some examples of possible semantics of different TS_SECLABELs in TSi and TSr? Sending different security labels in different directions? Just for curiosity. 9. Section 3.2: Rekey of an IPsec SA MUST only use identical Traffic Selectors, which means the same TS Type and selectors MUST be used. This guarantees that a Security Label once negotiated, remains part of the IPsec SA after a rekey. I think it is a too strong requirement. Traditionally in IKEv2 the rekey operation is equivalent to creating a new Child SA with full negotiation of algorithms and TSs. I know that there is an effort to make thing simpler in most cases, but I don't think status quo should be changed for generic case. I prefer to remove this para. Regards, Valery. > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Tero Kivinen > Sent: Tuesday, July 27, 2021 1:45 AM > To: ipsec@ietf.org > Subject: [IPsec] WGLC of draft-ietf-ipsecme-labeled-ipsec > > 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 > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Aug 27 06:00: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 6853D3A147E; Fri, 27 Aug 2021 06:00:45 -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, kivinen@iki.fi X-Test-IDTracker: no X-IETF-IDTracker: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163006924533.22353.10317496877694038223@ietfa.amsl.com> Date: Fri, 27 Aug 2021 06:00:45 -0700 Archived-At: Subject: [IPsec] ipsecme - New Meeting Session Request for IETF 112 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, 27 Aug 2021 13:00:46 -0000 A new meeting session request has just been submitted by Tero Kivinen, a Chair of the ipsecme working group. --------------------------------------------------------- Working Group Name: IP Security Maintenance and Extensions Area Name: Security Area Session Requester: Tero Kivinen Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 30 Conflicts to Avoid: People who must be present: Yoav Nir Tero Kivinen Benjamin Kaduk Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sun Aug 29 22:22: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 3F1A43A0DFA for ; Sun, 29 Aug 2021 22:22:15 -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, RCVD_IN_MSPIKE_H2=-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 pjrO38pGFq-2 for ; Sun, 29 Aug 2021 22:22:10 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DE2A3A0DFB for ; Sun, 29 Aug 2021 22:22:10 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4CD62F406DB; Sun, 29 Aug 2021 22:21:51 -0700 (PDT) To: rfc-editor@rfc-editor.org X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Cc: guqingyuan00@gmail.com, charliekaufman@outlook.com, paul.hoffman@vpnc.org, nir.ietf@gmail.com, pe@iki.fi, kivinen@iki.fi, ipsec@ietf.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20210830052151.4CD62F406DB@rfc-editor.org> Date: Sun, 29 Aug 2021 22:21:51 -0700 (PDT) Archived-At: Subject: [IPsec] [Editorial Errata Reported] RFC7296 (6667) 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, 30 Aug 2021 05:22:16 -0000 The following errata report has been submitted for RFC7296, "Internet Key Exchange Protocol Version 2 (IKEv2)". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6667 -------------------------------------- Type: Editorial Reported by: Qingyuan Gu Section: 3.3 Original Text ------------- For example, to propose ESP with (3DES or AES-CBC) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two Transform Type 1 candidates (one for 3DES and one for AEC-CBC) and two Transform Type 3 candidates (one for HMAC_MD5 and one for HMAC_SHA). Corrected Text -------------- For example, to propose ESP with (3DES or AES-CBC) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two Transform Type 1 candidates (one for 3DES and one for AES-CBC) and two Transform Type 3 candidates (one for HMAC_MD5 and one for HMAC_SHA). Notes ----- "AES" is misspelled as "AEC". Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7296 (draft-kivinen-ipsecme-ikev2-rfc5996bis-04) -------------------------------------- Title : Internet Key Exchange Protocol Version 2 (IKEv2) Publication Date : October 2014 Author(s) : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, T. Kivinen Category : INTERNET STANDARD Source : IP Security Maintenance and Extensions Area : Security Stream : IETF Verifying Party : IESG From nobody Mon Aug 30 01:08:24 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 DC7983A1929 for ; Mon, 30 Aug 2021 01:08:21 -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 cL04mQjRFPj7 for ; Mon, 30 Aug 2021 01:08:16 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D84563A1927 for ; Mon, 30 Aug 2021 01:08:15 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4GyjcR5gjwz3BD; Mon, 30 Aug 2021 10:08:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1630310887; bh=vmQ2alZKZdi33hTt/k/SjDVfpSGCrvlDdh1zoUgbkz0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=EpIuc8uGNsg94fiG2iEgWdcuiDC9LTt1MGyu3wbPn5yFC9xh7HnDT1YXTkxvWFKZv wNQgl6+/h47fpzNj9Cu9wnIMVCkw6eq9fh0/CjVeE4g0AXXul3ulvYj0FN2yKl2TPm P6SxyvuxzD/ojyq6x5Jv2egZwplMZvDNVxkHe93o= 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 soqKCxAK2W2x; Mon, 30 Aug 2021 10:08: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; Mon, 30 Aug 2021 10:08:06 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 25839ECBAF; Mon, 30 Aug 2021 04:08:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 23D60ECBAE; Mon, 30 Aug 2021 04:08:05 -0400 (EDT) Date: Mon, 30 Aug 2021 04:08:05 -0400 (EDT) From: Paul Wouters To: RFC Errata System cc: guqingyuan00@gmail.com, nir.ietf@gmail.com, pe@iki.fi, paul.hoffman@vpnc.org, kivinen@iki.fi, ipsec@ietf.org, charliekaufman@outlook.com In-Reply-To: <20210830052151.4CD62F406DB@rfc-editor.org> Message-ID: References: <20210830052151.4CD62F406DB@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] [Editorial Errata Reported] RFC7296 (6667) 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, 30 Aug 2021 08:08:22 -0000 On Sun, 29 Aug 2021, RFC Errata System wrote: > Original Text > ------------- > For example, to propose ESP with (3DES or > AES-CBC) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain > two Transform Type 1 candidates (one for 3DES and one for AEC-CBC) > and two Transform Type 3 candidates (one for HMAC_MD5 and one for > HMAC_SHA). > > Corrected Text > -------------- > For example, to propose ESP with (3DES or > AES-CBC) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain > two Transform Type 1 candidates (one for 3DES and one for AES-CBC) > and two Transform Type 3 candidates (one for HMAC_MD5 and one for > HMAC_SHA). > > Notes > ----- > "AES" is misspelled as "AEC". Indeed, there is a typo and this is the correct fix. Paul