From nobody Thu Jul 2 17:23:16 2020 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 078F83A097E; Thu, 2 Jul 2020 17:20:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: kaduk@mit.edu, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159373563801.30173.13159375600133119665@ietfa.amsl.com> Date: Thu, 02 Jul 2020 17:20:38 -0700 Archived-At: Subject: [IPsec] ipsecme - Requested session has been scheduled for IETF 108 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, 03 Jul 2020 00:20:50 -0000 Dear Yoav Nir, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ipsecme Session 1 (1:40 requested) Tuesday, 28 July 2020, Session I 1100-1240 Room Name: Room 6 size: 6 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/108/sessions/ipsecme.ics Request Information: --------------------------------------------------------- Working Group Name: IP Security Maintenance and Extensions Area Name: Security Area Session Requester: Yoav Nir Number of Sessions: 1 Length of Session(s): 100 Minutes Number of Attendees: 30 Conflicts to Avoid: Chair Conflict: tls acme Technology Overlap: cfrg People who must be present: Yoav Nir Tero Kivinen Benjamin Kaduk Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Jul 2 22:02:32 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D093A0CA1 for ; Thu, 2 Jul 2020 22:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 LuzeIcNMP3il for ; Thu, 2 Jul 2020 22:02:30 -0700 (PDT) Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (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 B182C3A0CA0 for ; Thu, 2 Jul 2020 22:02:29 -0700 (PDT) Received: by mail-ej1-x632.google.com with SMTP id o18so28310236eje.7 for ; Thu, 02 Jul 2020 22:02:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=/1I9pMKXYLSijygitVz3tR1TlGg10rsC+cFdWu430gc=; b=FxWKSXPQQ4//k7ThwRWSHyMJ840XLGIArlybG/gOMSQnCQX3Sg1LDKTyQdGKQ87o4L Gvlb566jHwv/aZKvI60oeYViV+jupgXvtIqx2iKB2cMjZzd9JIwQKS6uw+Xci9obzRJw z15AJc3mQM+KjSkHiC08AD5mc5GZ5+Sn7YRbNuvUBiViN7LOWS4zQrOheZQPe1cR8Ejc udgkX9yuJHYUHi/nPPII9YdU8RHe2jjkCG/msqxGzRu+DDGm/MlSq2+UbdsRDTvjatw2 F2EY1SfEmveAbMy9upEjwPYbNM7Mb2Hs+E5CD5E92mpzoxiiVv0igDktXA/o91TG9c+Y Z+2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=/1I9pMKXYLSijygitVz3tR1TlGg10rsC+cFdWu430gc=; b=Fcm/w2F8el8UevXwzS9gBNor/GHSi63ndi3oNSn1pLmIFG3j8U8AqKYyrCk+7QoeXl xrE8L/1soY8bKrcY/3LYKLWJQ3d35BCf5PC379PWxs/FHuXoUAYc01e+Tf6P22MNqJWY ShjXXLxcPOyiv3pgsTBLKvUoyBgZye2eg/0ulIZC39NaKVHZ2cj4NHdnWoOgLjpth4Hr 4VkCkGS3hfoeYDr+Hq7ooh5TODpe5d7Zozvm46/FJQRok/DiIL9QYUzkXZnRZXMg+ON1 BQdgQyP+XsiKTKntZAfZr0QqedYMe1Yx+l7cEuwdsMUrAFSBLnLH72+kpxrrJH76xMwU aI7g== X-Gm-Message-State: AOAM532rAHel+rBQQ97F7mHKznQHu9FSeOZKQqMLda4+REtl3BJrcis1 NBpjO3FG2y5DoLw/LbbsXic/Uq5i X-Google-Smtp-Source: ABdhPJxjvnXP0CA0nzYSXbpF9R9eo8GYpPsPri42YOuK4WJhxf3gzkNi49vkkgqm/dfA5lIOw6lWIA== X-Received: by 2002:a17:906:444e:: with SMTP id i14mr18118022ejp.418.1593752547800; Thu, 02 Jul 2020 22:02:27 -0700 (PDT) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id s10sm8937666ejs.91.2020.07.02.22.02.26 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Jul 2020 22:02:26 -0700 (PDT) From: Yoav Nir Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 3 Jul 2020 08:02:24 +0300 References: <159373563801.30173.13159375600133119665@ietfa.amsl.com> To: "ipsec@ietf.org WG" In-Reply-To: <159373563801.30173.13159375600133119665@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [IPsec] ipsecme - Requested session has been scheduled for IETF 108 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, 03 Jul 2020 05:02:31 -0000 Hi, all Notice that the times for our session is stated in UTC. 11:00 UTC is = 13:00 in Madrid (where we were supposed to meet), 14:00 in Moscow and = Israel, 7:00 AM in the eastern US, 4:00 AM (sorry, folks) in the Pacific = US, and 19:00 in Beijing. If you need a time-slot for this meeting, please send your request to = the chairs. Valery has already sent three requests; no need to re-send = them. Tero & Yoav > On 3 Jul 2020, at 3:20, IETF Secretariat wrote: >=20 > Dear Yoav Nir, >=20 > The session(s) that you have requested have been scheduled. > Below is the scheduled session information followed by > the original request.=20 >=20 >=20 > ipsecme Session 1 (1:40 requested) > Tuesday, 28 July 2020, Session I 1100-1240 > Room Name: Room 6 size: 6 > --------------------------------------------- >=20 >=20 > iCalendar: = https://datatracker.ietf.org/meeting/108/sessions/ipsecme.ics >=20 > Request Information: >=20 >=20 > --------------------------------------------------------- > Working Group Name: IP Security Maintenance and Extensions > Area Name: Security Area > Session Requester: Yoav Nir >=20 >=20 > Number of Sessions: 1 > Length of Session(s): 100 Minutes > Number of Attendees: 30 > Conflicts to Avoid:=20 > Chair Conflict: tls acme > Technology Overlap: cfrg >=20 >=20 >=20 >=20 >=20 >=20 > People who must be present: > Yoav Nir > Tero Kivinen > Benjamin Kaduk >=20 > Resources Requested: >=20 > Special Requests: >=20 > --------------------------------------------------------- >=20 >=20 From nobody Tue Jul 7 07:55:18 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0E33A0DAD for ; Tue, 7 Jul 2020 07:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-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 GYApxv_BlVZo for ; Tue, 7 Jul 2020 07:55:12 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BD1C3A0E0A for ; Tue, 7 Jul 2020 07:54:53 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 7541A548068 for ; Tue, 7 Jul 2020 16:54:50 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 6D835440043; Tue, 7 Jul 2020 16:54:50 +0200 (CEST) Date: Tue, 7 Jul 2020 16:54:50 +0200 From: Toerless Eckert To: "ipsec@ietf.org WG" Message-ID: <20200707145450.GB13952@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [IPsec] IPsec NSA recommendations 108 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, 07 Jul 2020 14:55:15 -0000 https://media.defense.gov/2020/Jul/02/2002355501/-1/-1/0/CONFIGURING_IPSEC_VIRTUAL_PRIVATE_NETWORKS_2020_07_01_FINAL_RELEASE.PDF No Swans mentioned ;-( From nobody Tue Jul 7 09:26:43 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD5D3A10EC for ; Tue, 7 Jul 2020 09:26:41 -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 srLdc7XEMkFI for ; Tue, 7 Jul 2020 09:26:39 -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 2D38C3A10E6 for ; Tue, 7 Jul 2020 09:26:38 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4B1SW10PsKzFdk; Tue, 7 Jul 2020 18:26:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1594139197; bh=A3CapJ7ihiPdAqsbUDbxcjl7V6+4Tg+Bnx1aWKbxyC0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=OAPBT+9YlbCKSw/KWmr8JdIrYinU1gY4GKj/ythLI/LCE6V8d+c1CIsRZKXbvbDv5 m7vJ9zvcGhe+NtTKLF80uzMEyoiKhqzaIYis9JJoVKtw13ZMSZYZGbaX4LhLhSgcG5 jPgbI0J0DITqUWYwqT4ML/EWv2Ezq3BKbz1ZB+bk= 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 RVyzJNlYK2XA; Tue, 7 Jul 2020 18:26:34 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 7 Jul 2020 18:26:34 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 081C86029BA5; Tue, 7 Jul 2020 12:26:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 07382384C6; Tue, 7 Jul 2020 12:26:34 -0400 (EDT) Date: Tue, 7 Jul 2020 12:26:33 -0400 (EDT) From: Paul Wouters To: Toerless Eckert cc: "ipsec@ietf.org WG" In-Reply-To: <20200707145450.GB13952@faui48f.informatik.uni-erlangen.de> Message-ID: References: <20200707145450.GB13952@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] IPsec NSA recommendations 108 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, 07 Jul 2020 16:26:41 -0000 On Tue, 7 Jul 2020, Toerless Eckert wrote: > Subject: [IPsec] IPsec NSA recommendations 108 > > https://media.defense.gov/2020/Jul/02/2002355501/-1/-1/0/CONFIGURING_IPSEC_VIRTUAL_PRIVATE_NETWORKS_2020_07_01_FINAL_RELEASE.PDF > > No Swans mentioned ;-( Last week, NIST released an update to SP 800-77 "Guide to IPsec VPNs". I'm one of the authors: https://csrc.nist.gov/publications/detail/sp/800-77/rev-1/final You will find both libreswan and strongswan examples there :) The NSA document recommends DH 16 as minimum over DH14, SHA2-384 as minimum over SHA2_256 and AES256 over AES128. I can understand the last one due to Grover's algorithm reducing the effective keysize to half, but I'm not sure where the DH and SHA2 recommendations come from. Does anyone know their reasoning? Paul From nobody Fri Jul 10 05:23:56 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81BD13A0C16 for ; Fri, 10 Jul 2020 05:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phbk_Ybxk3fS for ; Fri, 10 Jul 2020 05:23:53 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id BEF2C3A0C15 for ; Fri, 10 Jul 2020 05:23:52 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 4FD3660F1D; Fri, 10 Jul 2020 12:23:52 +0000 (UTC) From: Christian Hopps Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <15B34898-8D28-407B-A7FE-F31FCEAF47E5@chopps.org> Date: Fri, 10 Jul 2020 08:23:52 -0400 Cc: Christian Hopps To: IPsecME WG X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [IPsec] Early Allocation Request for IPTFS protocol number 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, 10 Jul 2020 12:23:55 -0000 Hi, Based on the list discussion I put together a draft early allocation = request (using the form https://www.iana.org/form/protocol-assignment) I think this is ready for the chairs to forward along to the AD/IESG per = section 2 of RFC7120. Request Description: Early Allocation Request Which registry are you requesting this assignment/registration be made = in? Assigned Internet Protocol Numbers If possible, please give a brief description of why you need this = assignment/registration: Aid in the early deployment and interoperability testing of = implementations of the documented protocol. According to RFC 4303 = (https://tools.ietf.org/html/rfc4303#section-2.6) the IPsec/ESP next = header field is chosen from the IP protocol number space. This is = because it transports IP packets or IP payloads. IPTFS is a new payload = type for ESP. The IPTFS payload type may eventually be used outside of = ESP; however, these uses are outside the scope of the defining document. Additional Information. Please include a reference to the specification = or RFC (if available) that defines this number or name space: draft-ietf-ipsecme-iptfs-01 From nobody Fri Jul 10 11:06:41 2020 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6B83A07E3; Fri, 10 Jul 2020 11:06:40 -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.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <159440440019.16747.8004884783576556673@ietfa.amsl.com> Date: Fri, 10 Jul 2020 11:06:40 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-multiple-ke-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 18:06:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Multiple Key Exchanges in IKEv2 Authors : C. Tjhai M. Tomlinson G. Bartlett S. Fluhrer D. Van Geest O. Garcia-Morchon Valery Smyslov Filename : draft-ietf-ipsecme-ikev2-multiple-ke-01.txt Pages : 23 Date : 2020-07-07 Abstract: This document describes how to extend the Internet Key Exchange Protocol Version 2 (IKEv2) to allow multiple key exchanges to take place while computing a shared secret during a Security Association (SA) setup. The primary application of this feature in IKEv2 is the ability to perform one or more post-quantum key exchanges in conjunction with the classical (Elliptic Curve) Diffie-Hellman key exchange, so that the resulting shared key is resistant against quantum computer attacks. Another possible application is the ability to combine several key exchanges in situations when no single key exchange algorithm is trusted by both initiator and responder. This document updates RFC7296 by renaming a transform type 4 from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and renaming a field in the Key Exchange Payload from "Diffie-Hellman Group Num" to "Key Exchange Method". It also renames an IANA registry for this transform type from "Transform Type 4 - Diffie- Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange Method Transform IDs". These changes generalize key exchange algorithms that can be used in IKEv2. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-multiple-ke/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-multiple-ke-01 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-multiple-ke-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-multiple-ke-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 12 23:29:14 2020 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BFAB83A0DC5; Sun, 12 Jul 2020 23:29:08 -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.8.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <159462174867.19497.16427475944619409741@ietfa.amsl.com> Date: Sun, 12 Jul 2020 23:29:08 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-g-ikev2-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 06:29:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Group Key Management using IKEv2 Authors : Valery Smyslov Brian Weis Filename : draft-ietf-ipsecme-g-ikev2-01.txt Pages : 59 Date : 2020-07-12 Abstract: This document presents an extension to the Internet Key Exchange version 2 (IKEv2) protocol for the purpose of a group key management. The protocol is in conformance with the Multicast Security (MSEC) key management architecture, which contains two components: member registration and group rekeying. Both components require a Group Controller/Key Server to download IPsec group security associations to authorized members of a group. The group members then exchange IP multicast or other group traffic as IPsec packets. This document obsoletes RFC 6407. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-g-ikev2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-g-ikev2-01 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-g-ikev2-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-g-ikev2-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 12 23:55:11 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA323A0E43 for ; Sun, 12 Jul 2020 23:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3qaq86aA3R5 for ; Sun, 12 Jul 2020 23:55:08 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 4C7CE3A0FD0 for ; Sun, 12 Jul 2020 23:54:47 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id q7so15684456ljm.1 for ; Sun, 12 Jul 2020 23:54:47 -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=GBZlwSR0Qv/D/b0GyYvRwodmC+/QhCpVurwr9vDMFtg=; b=QeWaDKZQ8u+zmvFCBACOF24Fl0EeVDrNbNVRaHfgbPK7Ab1EmOJOU++8M2cbgnyhXS 56mVj+knfxoIkC/J51qh9d1aEFKjpvhidjl/5+eFak/0ZkFJYTMF0q01lgoek7V2yZ5B UW6fPvIL7U5qB/5REiaZWvYoBn0yopDfb4GMjV2/NyH/mpKwEhB0gA2PD+cL+Vuck1qr +5OR5N09URUSjBJQaZ8oSDdZgc2qtld3+2uaVcXGvrQVABMc3LLsqjYafwlal/8RikI5 kJbXvcdoJOQKmQg2ZQZU8Mqn3bNFbJdIvGDcTmqDBNlf2uBZBZ2ikTMfCkQIJja1qha2 Vr4Q== 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=GBZlwSR0Qv/D/b0GyYvRwodmC+/QhCpVurwr9vDMFtg=; b=sd48MU5+TPm9coGw3MU+vSx7dV/SaN1sEWaXL5+SPj85hE4H4b2vVcgZW7zKNkAK0W JmodtT7VboTl7JpqNeq3hlmxnSokSJltQGo8l9OOyDXZ+5GMbACPxZkjD/pweDyV5C4x SPqN+0RyOVjYeESy+P1jHi6Jfe+jMBQboaATE6wg0tB6VNrQO0fy2OVBlycCTIqVc4jm z88maDhh9hnFE1m26aY39q9uTlf0wfVpyMrHG2PrbyUpVee2AYIbuYNYlvf0pIaw9Lt9 Ot9NavnXP3oaJF11sEPKtUc19XNvEk0kvXo8TUVMJ8+/s36I6rcVNlR0e/CqPk/G/8st hu6g== X-Gm-Message-State: AOAM530UQNatQFzMthY6TN0glXA4Djv6wpQl29D9lsVCakblgqj+n3HM wLtu1tHre+W/8vsBMrU2ND9J6z/H X-Google-Smtp-Source: ABdhPJy5FJxTrDFeVOBWTee5PxGd7Gogb+tFNJDJpKLCQl4xChKqWIDrcMse5emvfR5zq+Cjv8x1Zg== X-Received: by 2002:a2e:8191:: with SMTP id e17mr45191582ljg.339.1594623285061; Sun, 12 Jul 2020 23:54:45 -0700 (PDT) Received: from buildpc ([82.138.51.3]) by smtp.gmail.com with ESMTPSA id v25sm3904117ljg.95.2020.07.12.23.54.44 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Jul 2020 23:54:44 -0700 (PDT) From: "Valery Smyslov" To: References: <159440440019.16747.8004884783576556673@ietfa.amsl.com> In-Reply-To: <159440440019.16747.8004884783576556673@ietfa.amsl.com> Date: Mon, 13 Jul 2020 09:54:44 +0300 Message-ID: <1d1001d658e2$7d9a3680$78cea380$@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: AQH82UABS53vvxOykPqHVnvtCebFMqi4Edew Content-Language: ru Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-multiple-ke-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 06:55:10 -0000 Hi, the new version of the draft has very few changes: references are updated and nits are fixed. Regards, Valery (for the authors). > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. > > Title : Multiple Key Exchanges in IKEv2 > Authors : C. Tjhai > M. Tomlinson > G. Bartlett > S. Fluhrer > D. Van Geest > O. Garcia-Morchon > Valery Smyslov > Filename : draft-ietf-ipsecme-ikev2-multiple-ke-01.txt > Pages : 23 > Date : 2020-07-07 > > Abstract: > This document describes how to extend the Internet Key Exchange > Protocol Version 2 (IKEv2) to allow multiple key exchanges to take > place while computing a shared secret during a Security Association > (SA) setup. The primary application of this feature in IKEv2 is the > ability to perform one or more post-quantum key exchanges in > conjunction with the classical (Elliptic Curve) Diffie-Hellman key > exchange, so that the resulting shared key is resistant against > quantum computer attacks. Another possible application is the > ability to combine several key exchanges in situations when no single > key exchange algorithm is trusted by both initiator and responder. > > This document updates RFC7296 by renaming a transform type 4 from > "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and > renaming a field in the Key Exchange Payload from "Diffie-Hellman > Group Num" to "Key Exchange Method". It also renames an IANA > registry for this transform type from "Transform Type 4 - Diffie- > Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange > Method Transform IDs". These changes generalize key exchange > algorithms that can be used in IKEv2. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-multiple-ke/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-multiple-ke-01 > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-multiple-ke-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-multiple-ke-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Jul 13 00:56:32 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48BB43A0A4A for ; Mon, 13 Jul 2020 00:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3psHKAcjPhp5 for ; Mon, 13 Jul 2020 00:56:30 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450: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 413303A0A43 for ; Mon, 13 Jul 2020 00:55:52 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id f5so15990666ljj.10 for ; Mon, 13 Jul 2020 00:55:52 -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=PCWxDjTMxL5HUXch3u917mFNhu/2+AOtP6M+Ft1zoKM=; b=b860uBnDARn1OSj+/p6vGoGUFL70XOcbsWSkbsY3iB4JIsqy2H1ihhbcdXVM5bTtLf ha2d2EzLPC3x/QGa6a3D13RGs9ntkeI+IW+Y2OdAb/DQ2WFZuycWt7X1641E/D5QWyZo ib9q4+2qjQ/cAn9X+k83kI+yv5Jvu7gl5zvj0D3P+DW/MdDiFNfS7t1hPMb45S2rD07a Ul4HKqaBmlrhcG0B+nT4r9QGhSpQI1AOY4sJF4Zj7/B2SicyTwbem1zy3rJ6PQyVOHz7 rSq85kQLLCKjg9S5oF+IpfxEkcmNYnMIiEgsmKnIV9BumAsIW5BrYBX6lptF29U1Jbfz CnJg== 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=PCWxDjTMxL5HUXch3u917mFNhu/2+AOtP6M+Ft1zoKM=; b=Ztvhi4tK6KmqWLnD2/8vQvGE216hkOYT19ZyqCHqL0wSvVWtY8/MCyJSsfC9w90ZPK NBHlsfR3ZhUW+AqL8Gh51jvvcPydfgDazg23YmbQIgSZTxauRhMNkaK+NhWfECIq6V5s n9bKMFB/snbj4C/efgaqHu1Ao03HGzikM3rHB4UCwu7FxVKYMp9muTSuvOKA0YRos/1Z Q6namFQ2T83tKuOVHnErtjX+vEw24zwgOiD62QklD+jG4GouhwWLwJq95qUKnlaBhgMG IaNlrSV1O8qQDEes2CBdrlmnT+NLm275AdAXJS+BB1SaNVivBASl6ISCTEKa/rxSaLtk TutA== X-Gm-Message-State: AOAM531J9srOekzDBVFAtTQiFntAwe1YMOezmnSefdxJ10tX4d3W6Rn4 sIS0DX7Hyemgc3ZqL2lGREYFGZ2L X-Google-Smtp-Source: ABdhPJyYr4rRAyA3K8WXuuut1dVKGxq+6RxBJantqyDIKJexbxaPll74rbcIREthgF5Ty82UV+qQyQ== X-Received: by 2002:a2e:3619:: with SMTP id d25mr47431328lja.204.1594626949860; Mon, 13 Jul 2020 00:55:49 -0700 (PDT) Received: from buildpc ([82.138.51.3]) by smtp.gmail.com with ESMTPSA id v11sm3943833ljh.119.2020.07.13.00.55.49 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Jul 2020 00:55:49 -0700 (PDT) From: "Valery Smyslov" To: References: <159462174867.19497.16427475944619409741@ietfa.amsl.com> In-Reply-To: <159462174867.19497.16427475944619409741@ietfa.amsl.com> Date: Mon, 13 Jul 2020 10:55:48 +0300 Message-ID: <1d1701d658eb$060c8150$122583f0$@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: AQJThj0DVC6pi3Fz/DqupZwIV3yA+qgKvK9w Content-Language: ru Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-g-ikev2-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 07:56:31 -0000 Hi, the -01 version of G-IKEv2 protocol has a lot of changes compared to the -00. After some discussion among authors the draft has received some conceptual changes. 1. The protocol is now considered more like an IKEv2 extension (although a complex one), than like a new protocol based on IKEv2 wire format. So it is made closer to IKEv2 by re-using as many IKEv2 structures as possible. This approach required introduction of new IKEv2 transforms to be able to follow IKEv2 approach of defining SA parameters. The protocol now re-use IKEv2 IANA registry instead of defining its own. 2. Based on this approach the wire format is simplified and unified. It is no longer compatible with previous versions of the draft, however the changes are made in such a way, that it is always possible to distinguish between old and new formats. 3. The way SA keys are distributed is changed so that all keys are always transferred in encrypted form (even inside SA). The key distribution is performed in such a way, that for the GM the algorithm of obtaining the keys doesn't change when the GCKS implements more complex group key management schemes, like LKH. A lot of clarifications were added to eliminate possible ambiguities. We solicit reviews of the new version and discussions of these changes. Regards, Valery (for the authors). > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. > > Title : Group Key Management using IKEv2 > Authors : Valery Smyslov > Brian Weis > Filename : draft-ietf-ipsecme-g-ikev2-01.txt > Pages : 59 > Date : 2020-07-12 > > Abstract: > This document presents an extension to the Internet Key Exchange > version 2 (IKEv2) protocol for the purpose of a group key management. > The protocol is in conformance with the Multicast Security (MSEC) key > management architecture, which contains two components: member > registration and group rekeying. Both components require a Group > Controller/Key Server to download IPsec group security associations > to authorized members of a group. The group members then exchange IP > multicast or other group traffic as IPsec packets. This document > obsoletes RFC 6407. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-g-ikev2/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ipsecme-g-ikev2-01 > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-g-ikev2-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-g-ikev2-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Jul 13 14:33:54 2020 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DEBEC3A0C39; Mon, 13 Jul 2020 14:33: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.8.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <159467603387.10733.2207452954664791715@ietfa.amsl.com> Date: Mon, 13 Jul 2020 14:33:53 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-labeled-ipsec-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 21:33: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 : Labeled IPsec Traffic Selector support for IKEv2 Authors : Paul Wouters Sahana Prasad Filename : draft-ietf-ipsecme-labeled-ipsec-03.txt Pages : 8 Date : 2020-07-13 Abstract: This document defines a new Traffic Selector (TS) Type for Internet Key Exchange version 2 to add support for negotiating Mandatory Access Control (MAC) security labels as a traffic selector of the Security Policy Database (SPD). Security Labels for IPsec are also known as "Labeled IPsec". The new TS type is TS_SECLABEL, which consists of a variable length opaque field specifying the security label. This document updates the IKEv2 TS negotiation specified in RFC 7296 Section 2.9. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-labeled-ipsec/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-labeled-ipsec-03 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-labeled-ipsec-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-labeled-ipsec-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 16 09:47:51 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0323A0C69; Thu, 16 Jul 2020 09:47: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 (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 ab8_hfOjzCzH; Thu, 16 Jul 2020 09:47:46 -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 D55E53A0C52; Thu, 16 Jul 2020 09:47:44 -0700 (PDT) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id C34681B00258; Thu, 16 Jul 2020 19:47:41 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1594918061; 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=rnryd8/b/ywkO2H5UYxjjdc+xst7//siRYfJ9gQnzes=; b=XTd5ZM30ztCO/jftD0Rc8vYGTwDIwI1HHQxH9lkq1k7oNBuZaRzqWSAL5+pPAL+WZy3gBW CtSETzK3f717FZoseGIcHCO1vCA/2QO5q5WMPR3qLaQL7rVzeflFzvwqH0V6KJcLWS91v3 Bi/IRzxhahqMn7qgfiwahbTK86tU3/QlVgTNtwpP5SsHQoDXoCrETtaPpOHcTmXrTTOsz5 mLlxSpoOfetVBIaclPCcx1XUIdQea7V/HXvQbtVDTGyYV3xh7aiac486GkUCNCl/cZDwaK tWy9L/6ayc9cGRPWGAMxXTKly6YzELQ44R1VvHv3hVZNZEWSXM6p72Ij3XSqWA== Received: by fireball.acr.fi (Postfix, from userid 15204) id 9B16E25C109D; Thu, 16 Jul 2020 19:47:40 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24336.33964.354779.953171@fireball.acr.fi> Date: Thu, 16 Jul 2020 19:47:40 +0300 From: Tero Kivinen To: "'Toerless Eckert'" Cc: Michael Richardson , Paul Wouters , Valery Smyslov , ipsec@ietf.org, "'Yoav Nir'" , draft-ietf-anima-autonomic-control-plane@ietf.org In-Reply-To: <20200630202812.GF13952@faui48f.informatik.uni-erlangen.de> References: <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> <0b8001d5ecad$79ce7ad0$6d6b7070$@gmail.com> <0c9e01d5ed4c$2353f5a0$69fbe0e0$@gmail.com> <20200619145112.GA47906@faui48f.informatik.uni-erlangen.de> <24142.1592760359@localhost> <24309.64229.308771.733097@fireball.acr.fi> <20200626161053.GQ41244@faui48f.informatik.uni-erlangen.de> <24315.37346.143409.46224@fireball.acr.fi> <20200630202812.GF13952@faui48f.informatik.uni-erlangen.de> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 28 min X-Total-Time: 30 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1594918061; 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=rnryd8/b/ywkO2H5UYxjjdc+xst7//siRYfJ9gQnzes=; b=YrM/dIFrlSSrjRi212ZTVyvWPqxvMoBs6D97z0r4qznqwlscuFv8W9RbSQ7x8rc7YzVdI3 2X9wtyEloSGj6XicLB7dJ5W3J8UEcHhEmU2AYm1+3QHvm9MUkSVt5ZCK5L53bzCWQzb6tM u/wscek1guKuMqxxebzjbywWFcIKRpvoRZemxQUZCSWgBjA9Gssv0QP9Wz36tifGF6ROiz 3g1RIN9TJy6sX2Y9ETKMaAuGR5nMJUll0UBNQqveCSJP7mRwZRzBixuA8jLMvaqr/GVbdT NP5F+6CR1aVGr8VJcMygbArWVTriA1Aa8MgL4cbzzaXrHWpGyZaEfTUGEpPodg== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1594918061; a=rsa-sha256; cv=none; b=BbA42un11yib4rfUB1AO36GpEVF3xHaF1SoXpqrnmzl8Do3RaTrwqoz8t7kGkIeTS12z+a U+4+Pdok38f7Tus1S7xl3FcMrXGbHlUgXGCyTGIAAr1TCAtv1fFzblW2GN+Ne6wA4FkGtt fRh+9u2LNvR1sMTIuzCSp9tXX0MT+5lAJ1LLZor0LEgSWwmn1lst09UGcNVDX9Y0Rd2bJR z7pJTSuz7Z8BPHDdudiQTIsTDCYOvbzKCY8CUC+hgVVWVOwkCJi7LWHD6bv5UpBLWidgpr zHDDof17eNgiIOBkq1N/HWcf5kc3lFbtOoSRYMIItjQ1lYDYGtg9s97RyLdwEA== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [IPsec] Troubleshooting IPsec peer certs (was: Re: IPsec profile feedback wanted (draft autonomic control) plane) 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, 16 Jul 2020 16:47:50 -0000 'Toerless Eckert' writes: > > If you ever need to talk to devices that are not part of same > > authorization domain you need that feature (unless you want to > > provide lots of manual configuration to IKE). > > > > I.e., if you connect to SGW1, you need to use public/private key pair > > and certificate from CA1 to authenticate. And if you connect to SGW2 > > you need to use different public/private key pair and different > > certificate which is from CA2. > > > > You could manually list all possible SGW ip-addresses or names and > > configure that they must use specific CA, but that gets diffucult when > > the number of SGWs raise, can cause problems when certificates are > > renewed, as then you need to update your configuration again. > > > > So what IKEv2 does is that it will connect to the SGW, and SGW will > > tell that it requires you to use certificate signed by list of CAs and > > that list include for example CA1. Then initiator can select > > his own certificate from CA1, and the associated private key and use > > that when sending the IKE_AUTH to the other end. If he picks wrong CA, > > meaning wrong private key the responder will fail the authentication > > and connection is not established. > > > > Note, that the initiator does not really care which of his own private > > keys and associated certificate it uses, as all of them identify > > himself, he just need to pick something that is suitable for the > > remote peer. > > > > What the initiator needs to manually configure is that what kind of > > certificates are required by remote peer, i.e., which CA must have > > signed the certificate responder used. This is required for security > > so SGW1 cannot do IP or DNS hijack and claim to be SGW2 even when > > using CA1. Good thing for this is that we just configure that SGW1 > > needs to authenticate himself with cert from CA1, and SGW2 needs to > > use cert from CA2. > > > > Note, that initiator might not have any certificate from CA1 or CA2, > > it might actually use completely different CAs, i.e., the list of > > certificate authorities can be asymmetric. > > Good explanation. So, whats the most simple example for this ? > I have a single VPN but multiple geographic headends and > there is an obfuscated logic what certs each headends accepts, > so i do have multiple and certreq helps me to choose ? I would assume most common case will be when certificates are being renewed in non-compatible way. I.e., you initially have rsa certs for both client and server, then someone decides rsa is weak, and we must move to ecdsa in the future. They will first install new TA certs on the some servers (lets say they have 1000 of those, and they do not want to do all of them immediately). Now some of the servers do have TA1, and some have both TA1, and TA2. Next clients needs to get new certificates from TA2. This process can make months, as it is possible that some of the clients are not connecting to the server for long time. If you have client which has only TA1, there is no problem, it can connect to any server which still supports TA1. If you have client which has both TA1, and TA2, and it connects to old server which only supports TA1, it needs to recognize this and use TA1 in that case. If it connects to server using both TA1, and TA2, it most likely wants to prefer TA2, as that is the direction the transition is going, so TA2 should be preferred if both are supported. When all servers have been updated to support both TA1, and TA2, then there is no longer issues, as now all clients which do have TA2, use it for all servers, and those which have not yet updated to TA1, still use that. So the idea is to allow iterative updating of the system, without the need of flag days or configuration settings to specify things. I.e., IKEv2 will automatically detect which TA is supposed to be used, and use it. > I am sure everything is possible, i am just looking for the > most simple example where that is actually used. I think for > a specific VPN all my VPN clients always only had one cert. Current VPNs are quite often very strictly configured to use exactly the configuration they have, and quite often they use their own IPsec implementation, i.e., they might not use the IPsec provided by the operating system. Things get more complicated if you actually want to have multiple VPNs in your system each using the same operating system provided IPsec, but just provide configuration information to that. Of course in that case you might also have overlapping configurations causing issues, and thats why I think most of the VPNs are now standalone type of implementations. > > > And IPsec implementations are prone to not > > > support binding to different UDP ports for different purposes, > > > so there are always workarounds needed to support multiple > > > purposes on the same device simultaneously. > > > > In IKEv2 there is IDi, and IDr for specifying purposes mostly. When > > initiator connects to the host, it can send both IDi (who he is), and > > IDr (who he wants to talk to). Then responder can see that if he > > understands IDr (it might be FQDN like example.com or > > company2.com), and if so, it will return same IDr for its own > > identity. Initiator tells his own identity in the IDi. > > > > Responder can also return something completely different for IDr, if > > it does no recognize the IDr, or even if it recognizes, i.e. it might > > actually return IDr of mail.example.com when initiator send IDr of > > example.com. > > > > This is similar to what TLS and SNI does, or Host-header in the http. > > > > Again this is only hint, and responder can use that information, or it > > might ignore it if it feels like so. > > Ok, so i hope i am correct to state that in general we could have > ignored specifying IDi/IDr in our profile as its not necessary. > > I forgot who proposed we put our nodes IPv6 address into this > field, but the IPv6 address itself doesn't seem to be very > useful to identify whether the nodes are in the same network. > > The full name of a node was so far an rfc822Name, now i need to > fix it to become what i think is going to be a GeneralName, > and hence it might best be to signal IDi/IDr as ID_DER_ASN1_GN Note, that the IDi and IDr are what is matched against the IPsec policy, i.e., nothing in the certificate will cause policy to be selected, only IDi and IDr does that. After IDi and IDr identifies the suitable policy, we can go and match the information in the policy against the certificate. That policy might include information like how to match the certificate subject alt name or subject name to identity or information in the policy. It could even include the list of trusted TAs, but this has the problem that we need to send list of TAs before we know the ID of the other end, so in that case we need to send union of all possible TAs in all of our policies. > > Sending full chain including TA is not helpful at all in normal case, > > and is only marginally helpful for failure cases. The question is that > > do you want to waste resources 99.99% of time so that in the 0.01% > > cases there might be slight change that it might be helpful for when > > someone starts actually doing debugging. > > The use-case are long-lived IPsec connections between routers > that would stay up until a node reboots, a link fails or somebody > misplugs a cable. We had network operators that plugged in a UPS > to a router when they moved routers to a new building after 10 years, > just because they wanted to keep their router-uptime record. > > For all i care, IKEv2 could be performed by two dancing turtles > singing the packets. There is no advertisement revenue in this > use-case in faster IKEv2 handshake. Not even an annoyed toerless > waiting for his notebook VPN to come up ;-). Sure at some point > in time after this is sucessfull in enterprise SP backbone networks, > we will have to revisit optimizing for low-end IoT, but this particular > issue is by far not the only one for that space. > > We disagree on your surely scientifically analyzed benefit of > 0.001%. Even a 0.1 % of cases benefit could be a huge benefit. > In big, badly manaed pops, some link diagnostics is taking weeks > for folks to bring in better diagnostics gear. Can i promise > our idea for better IKEv2 diagnostic will help ? No, we can't but > we only need to establish IMHO that it does not hurt, and i think > it does not. Note, that to be able to see the TA sent you need debugging logs. The certificates are sent inside the encrypted packets, and only way to know what was there is to have IKEv2 implementation print that information to some kind of debugging log. So even if you send them inplace, that does not mean that you can actually use them when debugging. I would assume most of the mobile handset IPsec implementations do not provide such debugging logging in general, you might need to enable some kind of debugging mode or restart the system in a way where you can see console log etc. This same of course applies to the end entity certificate, and that might be issue, i.e., if the IPsec implementation does not even print that out then you have hard time debugging issues. > > I think it is better to save bytes 100% of time... > > You assume that you have other diagnostics channels, and if you > do, i do agree. In our case we're at the lowest level/first stuff > that establishes connectivity. As I said you need other diagnostic channels even if you send the TA, as it is inside encrypted packet. Of course if you can replace the device with another device having diagnostic prints and logging using same IP-address you can make claim to be the responder, and print debugging information out from there, but it does require you act as a responder yourself. In that case your special diagnostic tool can provide much better debugging information anyways than what is normally provided by the IPsec implementations. > > Especially when the content you are sending is binary blob > > which is quite meaningless unless you first decode it and show it to > > user somehow. What kind of user is going to see these debug printouts > > printing out the CA? > > I imagine a GUI at the NOC of a network operator: > > Unauthenticated ACP neigbhor on NodeXXX/InterfaceYYY: > node:@ > Click to see cert chain diagnostics > > And would show similar decode of the cert chain including TA > as you would get from e.g.: clicking on the trust icon on a browser. So you plan to have IPsec implementations actually saving that information somewhere, and providing that debugging information to that gui by some unspecified management protocol, i.e., modify the ipsec implementations you use to provide the information. Currently I think most of the implementations do not provide it in easy to use way... Luckily in IKEv2 you do need that information much less often than what happend with IKEv1, where there was lots of parameters which had to be exactly same in both ends, so only way to verify that was to have detailed debug logs and check what other end proposed, and what our policy required. > Thats about the minimum. I wish we would have not been called back > using rfc822Name for our solution, because then we could have > even easily authenticated such a peer from a different domain > by relying on ACME certificates. Oh well. -- kivinen@iki.fi From nobody Fri Jul 17 15:10:47 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15863A0972; Fri, 17 Jul 2020 15:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 nJnsw_YXM7Jn; Fri, 17 Jul 2020 15:10:39 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDCDD3A08B9; Fri, 17 Jul 2020 15:10:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 40D45389AC; Fri, 17 Jul 2020 18:07:35 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Mo4FrNKUFxU8; Fri, 17 Jul 2020 18:07:34 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 29D7F389AB; Fri, 17 Jul 2020 18:07:34 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AC92824C; Fri, 17 Jul 2020 18:10:36 -0400 (EDT) From: Michael Richardson To: Tero Kivinen , ipsec@ietf.org, anima@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org In-Reply-To: <24336.33964.354779.953171@fireball.acr.fi> References: <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> <0b8001d5ecad$79ce7ad0$6d6b7070$@gmail.com> <0c9e01d5ed4c$2353f5a0$69fbe0e0$@gmail.com> <20200619145112.GA47906@faui48f.informatik.uni-erlangen.de> <24142.1592760359@localhost> <24309.64229.308771.733097@fireball.acr.fi> <20200626161053.GQ41244@faui48f.informatik.uni-erlangen.de> <24315.37346.143409.46224@fireball.acr.fi> <20200630202812.GF13952@faui48f.informatik.uni-erlangen.de> <24336.33964.354779.953171@fireball.acr.fi> 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] Troubleshooting IPsec peer certs (was: Re: IPsec profile feedback wanted (draft autonomic control) plane) 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, 17 Jul 2020 22:10:41 -0000 --=-=-= Content-Type: text/plain Tero Kivinen wrote: Tero> Note, that initiator might not have any certificate from CA1 or CA2, Tero> it might actually use completely different CAs, i.e., the list of Tero> certificate authorities can be asymmetric. Toerless> Good explanation. So, whats the most simple example for this ? Toerless> I have a single VPN but multiple geographic headends and Toerless> there is an obfuscated logic what certs each headends accepts, Toerless> so i do have multiple and certreq helps me to choose ? > I would assume most common case will be when certificates are being > renewed in non-compatible way. I.e., you initially have rsa certs for > both client and server, then someone decides rsa is weak, and we must > move to ecdsa in the future. They will first install new TA certs on > the some servers (lets say they have 1000 of those, and they do not > want to do all of them immediately). Now some of the servers do have > TA1, and some have both TA1, and TA2. I am not really following this discussion very well. I'm not sure if this is general advice or ACP specific advince. In the case that you describe (RSA->ECDSA), I think that we would sign TA1 with TA2, or vice-versa. (probably one and then the other a month later). We can feed/update the trust anchors when certificates are renewed, or we can use draft-ietf-netconf-trust-anchors to change things (the advantages of having really good security for in-band management) I prefer relatively short expiries for certificates in the ACP because . I think that all systems have to support both RSA and ECDSA for a big overlapping period. I don't think this is a problem. I think that there is not a problem having a RSA key (TA1) sign an ECDSA EE cert. I know that I've done it, but I know that some think it uncool. > Next clients needs to get new certificates from TA2. This process can > m^Htake months, as it is possible that some of the clients are not > connecting to the server for long time. That's true in general, particularly for remote access situations, but ACP nodes are mostly always reachable. If they get turned off and put in a box, then when they return, they have a valid certificate, or they have to bootstrap again, and that's okay. > If you have client which has only TA1, there is no problem, it can > connect to any server which still supports TA1. If you have client > which has both TA1, and TA2, and it connects to old server which only > supports TA1, it needs to recognize this and use TA1 in that case. If > it connects to server using both TA1, and TA2, it most likely wants to > prefer TA2, as that is the direction the transition is going, so TA2 > should be preferred if both are supported. > When all servers have been updated to support both TA1, and TA2, then > there is no longer issues, as now all clients which do have TA2, use > it for all servers, and those which have not yet updated to TA1, still > use that. You are imagining a period of time where we are installing the trust anchors, and I don't see it has to be like that. Have TA1 sign TA2 as a sub-CA, and then pass out TA1->TA2->EE(ecdsa) chain to the new nodes. Once this is done for all nodes, you can drop TA1. In reality, there are probably at least an extra level of CA, possibly two. Do you think that I should include this situation into draft-richardson-registrar-operational-considerations? > So the idea is to allow iterative updating of the system, without the > need of flag days or configuration settings to specify things. I.e., > IKEv2 will automatically detect which TA is supposed to be used, and > use it. Agreed. >> The full name of a node was so far an rfc822Name, now i need to >> fix it to become what i think is going to be a GeneralName, >> and hence it might best be to signal IDi/IDr as ID_DER_ASN1_GN > Note, that the IDi and IDr are what is matched against the IPsec > policy, i.e., nothing in the certificate will cause policy to be > selected, only IDi and IDr does that. After IDi and IDr identifies the > suitable policy, we can go and match the information in the policy > against the certificate. That policy might include information like > how to match the certificate subject alt name or subject name to > identity or information in the policy. So, we've been forced to use otherName, and this will cause new code in some of the IKEv2 daemon that we need to use :-( -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8SIdwACgkQgItw+93Q 3WXDrAf+KARlPwJFjiNO8Kf3vQuYaDzeMTs1ypYxHSRQGZQumL58n4GEbr48QUpb hbi7Kb6JEyYAKt+pmNsqdxttylGMbhFOhJdctucuAJ3syou8QnJFMyWvowA9uZo7 MRztmClo5IcFG79DBgmr8vP8kKtPa+FwoTKJZwkk/rGy0zLPANLvi7pWTwpYskI3 aii7Nwwv2ouS5W51cs7pewTE6f8gEtji18XiaKblJ/4j7Ir3xy50afczPFeGVVtB v2lmxMeA2FSy0uSH3nfh3pc/A0xTvjRfoSgfn2MQzhtoeFbzLEKn3gjhed6Eonq+ 1eb/c1NqeY3JRzp4lclFjz4KEEwoRA== =YxUi -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 20 12:26:34 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9390B3A0E45 for ; Mon, 20 Jul 2020 12:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 AcE8QQNCo1eT for ; Mon, 20 Jul 2020 12:26:31 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 E1A833A0E43 for ; Mon, 20 Jul 2020 12:26:30 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id q5so18940883wru.6 for ; Mon, 20 Jul 2020 12:26:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=xaT0ede9QUeuoXJhwN35rjtyki2i/Oa7QZozM4dhWAs=; b=Eglw08ZJHchIKLL89tomb9CdCQ5kZ5aQSzkMMK2qkeVB6otCN5gD4TcMmejYSB9EaZ 3KZDODHYCGFvOaPFKT7BBJ+qsDJbe1bBcg6Xol3ah8+NGNybQcJVjrWPIAAVv19ljndU EPdGjQ2Gi0XKv7Cy66h2H4zy9I6WLQEl9IwD5JFEqbDhSJqgGNC3zcepXn4dn5cxGZUl 9JFbvlW0sJn3nqa1w7uFjEtrj94Wtk2XKEHxK885HbksDo7XECFmRN/sEu8PcjYayn0J gkXXsDQVUYk+NUPbbbfvt5kT/ts+6+SzZGydFtDGATYMJDe+ra0tbFnn/6vLWv2cPFFL janw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=xaT0ede9QUeuoXJhwN35rjtyki2i/Oa7QZozM4dhWAs=; b=Yr3TzeYi7ion7+uLk29GG70OUKuFJ3lfDB+A0GRJKEO/nB4wiZqvndqva60DqIdXvf 6ctUt2MefWbYEhPI8wKQEODu9JXAR1cpU9XrNriG5MwTbBcUu/cOb5bnFbN3+j32FQiu hJ7mFll+bSts/t4BluoIVDxbXlD7nE4sxASTu7sVJlsQU2YoCA3E3SobtDJfqdgeTSEe 00zVDCKJ2CVBm5IGTI0b0i6EVM2DKIHh+P1Xkm8Eg6er5hcQRWzmvHOhxY69D+n5CQOC +kFu9+TtaCPsA0tViVo+lwKcb/gD5spCd7qOI+2cp942UuS6CmCP0SF88cjYBa9P7OAV 0CrA== X-Gm-Message-State: AOAM531W0oB/HoeXxgrpzJe4YDH6SmGZ/p37oMY3ykARBD8BZiim25XG FuSTyfY6Aryr03p7DI+HhIcDN/49 X-Google-Smtp-Source: ABdhPJxSdjxXyXo5OLRiAu2htkBpBEwiZeDz8GvrPwqXyP+xDj6ZuvjueBbpKgVj4cDRxkwGAksyag== X-Received: by 2002:adf:8282:: with SMTP id 2mr8913107wrc.76.1595273189067; Mon, 20 Jul 2020 12:26:29 -0700 (PDT) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id 33sm38135860wri.16.2020.07.20.12.26.27 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Jul 2020 12:26:28 -0700 (PDT) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_7CB5FBB8-E583-415E-821F-0C75E10C03FD" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <8CE17297-AE71-4B5D-B6B7-AED17656BAD7@gmail.com> Date: Mon, 20 Jul 2020 22:26:26 +0300 To: "ipsec@ietf.org WG" X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [IPsec] Agenda Uploaded 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, 20 Jul 2020 19:26:33 -0000 --Apple-Mail=_7CB5FBB8-E583-415E-821F-0C75E10C03FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Please note that the times given are UTC. https://www.ietf.org/proceedings/108/agenda/agenda-108-ipsecme-00 = Yoav= --Apple-Mail=_7CB5FBB8-E583-415E-821F-0C75E10C03FD Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Please note that the times given are UTC.


Yoav
--Apple-Mail=_7CB5FBB8-E583-415E-821F-0C75E10C03FD-- From nobody Tue Jul 21 04:00:47 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1506E3A0A4F; Tue, 21 Jul 2020 04:00:41 -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 0uB6dn_Ow6is; Tue, 21 Jul 2020 04:00:38 -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 6AC543A0A4D; Tue, 21 Jul 2020 04:00:36 -0700 (PDT) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id F27731B00093; Tue, 21 Jul 2020 14:00:30 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1595329233; 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=fW4MRMERSVmCRkP0QlaUl3AwOvRUTMqZYp34H7s3rGQ=; b=QflMue2Zz4S+qKMtI2JInlwLLvH8kVTwXLXfiIbHQW5bInPaVt+fHJLNfpw/ZDI6Vp1YUf cEIJEyZ0czwlu+ZiNpn7kIlFpKPFZYjmir3UsGayvqboJo/FDh+7ArC3fcTX//Hmgua5yh 5TEJUtHQ7eCAMJo4lP+kecpKcxY1wjKt80dLV3YjhoFTlt93nME1/AihlP1kZBPoO74Jkx UA5JLuFwWQKhp2/nI5jZDrmF9WIWG2WmRBe56/nT2tcr3y03B8ahZRDXwbWK5CGHmUKpgs ge8njqVom4niCRlUJ8P3zoGEqXCVICYTduAxrhk36lH4f0dj30jXQYpO2UUJiw== Received: by fireball.acr.fi (Postfix, from userid 15204) id AEF5225C11CC; Tue, 21 Jul 2020 14:00:30 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24342.51918.664855.708819@fireball.acr.fi> Date: Tue, 21 Jul 2020 14:00:30 +0300 From: Tero Kivinen To: Michael Richardson Cc: ipsec@ietf.org, anima@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org In-Reply-To: <6871.1595023836@localhost> References: <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> <0b8001d5ecad$79ce7ad0$6d6b7070$@gmail.com> <0c9e01d5ed4c$2353f5a0$69fbe0e0$@gmail.com> <20200619145112.GA47906@faui48f.informatik.uni-erlangen.de> <24142.1592760359@localhost> <24309.64229.308771.733097@fireball.acr.fi> <20200626161053.GQ41244@faui48f.informatik.uni-erlangen.de> <24315.37346.143409.46224@fireball.acr.fi> <20200630202812.GF13952@faui48f.informatik.uni-erlangen.de> <24336.33964.354779.953171@fireball.acr.fi> <6871.1595023836@localhost> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 13 min X-Total-Time: 12 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1595329233; 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=fW4MRMERSVmCRkP0QlaUl3AwOvRUTMqZYp34H7s3rGQ=; b=S2KU7u3zyu+tSlBEG/8uLwKCJht9TbFIrNjqM31ygxCU6HqeR11N1ogHUaKxD/TNaMgevv 1lxX5BqFCDi3x0bpIqixgaeP86Zr62Cbr0r58JfsTbafd2GGml6uGxotdMmNj7B5t1ccN3 jtniKfOSEFHxTyjwaEw9z7ULmIe+osv+GsyljJSBKT58/+HE7S28ENGgIeiyxNkilecq3K 3FbRmxFwrbv8bKrCacDK+ndp94GSuJ1Kl+OVISkUt2ZHA4CMk5rQAWElVqKfx9FxbD4EJD UJ5d7FciR5ayc3Ne25NRKPRJ5Y7y9MSE8S5YTn6f42LamPsR18O4PG6pgrih4Q== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1595329233; a=rsa-sha256; cv=none; b=WzuPtvO3O+N/R/V81Ixka+crVTgUmqAuy9rgVvb42D8A4aFcIgLPSTv2uUTL+KyeNcveDd eJXxLtVhzxOeNIVHei2q9a7KtvqdWRAqs2IwaPQJf6q7WleTkI712p6TKE4HDUDvHz3WXG 6tlhMCdKBjaJtAI/xlf3wX5I1g/Vq2Hs4dVFb8HkwhCxRVK0PS+VOPFXqmCa4d+tnSt4Xf Thzzw0A+00Fr/mP2mpz05nX4q3aVg5g2MBB5RGS3uQiTszWzsClhoHYJW5gmn0TK43Xp5W T/QGle+HRzlFmgrj4Cs952rM8mTrAUCScf2D/jvITzzvtVOwZbTsTa6Znnq8tA== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [IPsec] Troubleshooting IPsec peer certs (was: Re: IPsec profile feedback wanted (draft autonomic control) plane) 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, 21 Jul 2020 11:00:41 -0000 Michael Richardson writes: > I am not really following this discussion very well. > I'm not sure if this is general advice or ACP specific advince. This discussion was not ACP specific, this was just generic reasons why CERTREQ etc are usuful in general. Anyways I think most ACP cases do not need CERTREQ, but on the other hand there might be cases where it is still useful there, and thats why I would hate to see profile that forbits its use. I.e., it is fine to say in profile, that CERTREQs might not be needed, but saying that they should/must not be sent is bad idea. > In the case that you describe (RSA->ECDSA), I think that we would sign TA1 > with TA2, or vice-versa. (probably one and then the other a month later). > We can feed/update the trust anchors when certificates are renewed, or we can > use draft-ietf-netconf-trust-anchors to change things (the advantages of > having really good security for in-band management) If you have proper management, then you can do almost instanteneous changes, but CERTREQ allows you do do similar things even when you do not have any kind of management system configuring devices, with much longer overlaps in configuration. > I prefer relatively short expiries for certificates in the ACP > because . I think that all systems have to support > both RSA and ECDSA for a big overlapping period. I don't think this > is a problem. > > I think that there is not a problem having a RSA key (TA1) sign an > ECDSA EE cert. I know that I've done it, but I know that some think > it uncool. Sometimes the problem is that there are devices there which do not support ECDSA at all, which means you are stuck with RSA for both root and EE for all devices. With CERTREQ some parts of the network can start use full ECDSA TA and EE and still interoperate with those devices which support both and get the "coolness" factor of not using RSA at all :-) Other similar cases comes when you merge authorization domains together, i.e., two companies merge and they both had their own CAs before, and not all devices support both CAs, so you need to pick correct certificate one when talking to one or another device. > You are imagining a period of time where we are installing the trust anchors, > and I don't see it has to be like that. > > Have TA1 sign TA2 as a sub-CA, and then pass out TA1->TA2->EE(ecdsa) > chain to the new nodes. Once this is done for all nodes, you can > drop TA1. In reality, there are probably at least an extra level of > CA, possibly two. > > Do you think that I should include this situation into draft-richardson-registrar-operational-considerations? The text I provided earlier was just general IPsec case, I have not checked out situation in this specific case, so I cannot comment on that before I read that document... > >> The full name of a node was so far an rfc822Name, now i need to > >> fix it to become what i think is going to be a GeneralName, > >> and hence it might best be to signal IDi/IDr as ID_DER_ASN1_GN > > > Note, that the IDi and IDr are what is matched against the IPsec > > policy, i.e., nothing in the certificate will cause policy to be > > selected, only IDi and IDr does that. After IDi and IDr identifies the > > suitable policy, we can go and match the information in the policy > > against the certificate. That policy might include information like > > how to match the certificate subject alt name or subject name to > > identity or information in the policy. > > So, we've been forced to use otherName, and this will cause new code in some > of the IKEv2 daemon that we need to use :-( No, you are not forced to use anything. Your ID could be KEY_ID with just random 128-bit binary blob, and you could find your policy entry based on that. Then in the policy entry there might be information what should be present in the certificate, or even just hash of the raw public key (which could be also be sent inside the certificate in some cases). IDi and IDr are used to find the policy, policy information is used to verify that the authorization information provided are correct. That information usually includes trust anchors, and information what should be in the certificate signed by those trust anchors. -- kivinen@iki.fi From nobody Tue Jul 21 07:54:31 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD573A09DE; Tue, 21 Jul 2020 07:54:30 -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 AqdsqLpbuG_g; Tue, 21 Jul 2020 07:54:28 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C0653A09DD; Tue, 21 Jul 2020 07:54:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id B0B1938A1E; Tue, 21 Jul 2020 10:34:01 -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 S53sxJWtEzh0; Tue, 21 Jul 2020 10:34:00 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 2AF0E38A1A; Tue, 21 Jul 2020 10:34:00 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6C3C03F; Tue, 21 Jul 2020 10:54:25 -0400 (EDT) From: Michael Richardson To: Tero Kivinen , ipsec@ietf.org, anima@ietf.org In-Reply-To: <24342.51918.664855.708819@fireball.acr.fi> References: <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> <0b8001d5ecad$79ce7ad0$6d6b7070$@gmail.com> <0c9e01d5ed4c$2353f5a0$69fbe0e0$@gmail.com> <20200619145112.GA47906@faui48f.informatik.uni-erlangen.de> <24142.1592760359@localhost> <24309.64229.308771.733097@fireball.acr.fi> <20200626161053.GQ41244@faui48f.informatik.uni-erlangen.de> <24315.37346.143409.46224@fireball.acr.fi> <20200630202812.GF13952@faui48f.informatik.uni-erlangen.de> <24336.33964.354779.953171@fireball.acr.fi> <6871.1595023836@localhost> <24342.51918.664855.708819@fireball.acr.fi> 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] Troubleshooting IPsec peer certs (was: Re: IPsec profile feedback wanted (draft autonomic control) plane) 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, 21 Jul 2020 14:54:30 -0000 --=-=-= Content-Type: text/plain Tero Kivinen wrote: >> I am not really following this discussion very well. >> I'm not sure if this is general advice or ACP specific advince. > This discussion was not ACP specific, this was just generic reasons > why CERTREQ etc are usuful in general. Anyways I think most ACP cases > do not need CERTREQ, but on the other hand there might be cases where > it is still useful there, and thats why I would hate to see profile > that forbits its use. I.e., it is fine to say in profile, that > CERTREQs might not be needed, but saying that they should/must not be > sent is bad idea. I hope that at no point do we forbid the use of anything. A peer might not expect it/do anything. The important part is that we say what pieces we *do* require. There is one more revision of ACP coming out on Monday, and I hope that is the last one that the IESG will approve on the next telechat. >> In the case that you describe (RSA->ECDSA), I think that we would sign TA1 >> with TA2, or vice-versa. (probably one and then the other a month later). >> We can feed/update the trust anchors when certificates are renewed, or we can >> use draft-ietf-netconf-trust-anchors to change things (the advantages of >> having really good security for in-band management) > If you have proper management, then you can do almost instanteneous > changes, but CERTREQ allows you do do similar things even when you do > not have any kind of management system configuring devices, with much > longer overlaps in configuration. I think that proper management will probably not be in revision 1 of products. However, a killer-use-case for the ACP is for SDN control channels, so I could be wrong. >> I prefer relatively short expiries for certificates in the ACP >> because . I think that all systems have to support >> both RSA and ECDSA for a big overlapping period. I don't think this >> is a problem. >> >> I think that there is not a problem having a RSA key (TA1) sign an >> ECDSA EE cert. I know that I've done it, but I know that some think >> it uncool. > Sometimes the problem is that there are devices there which do not > support ECDSA at all, which means you are stuck with RSA for both root > and EE for all devices. With CERTREQ some parts of the network can > start use full ECDSA TA and EE and still interoperate with those > devices which support both and get the "coolness" factor of not using > RSA at all :-) I think that we say that we will tolerate RSA :-) So you are right: there could be devices which do not do ECDSA on day one, and in which case, you can't switch the keys at all. > Other similar cases comes when you merge authorization domains > together, i.e., two companies merge and they both had their own CAs > before, and not all devices support both CAs, so you need to pick > correct certificate one when talking to one or another device. Yes, this is an important case. >> So, we've been forced to use otherName, and this will cause new code in some >> of the IKEv2 daemon that we need to use :-( > No, you are not forced to use anything. Your ID could be KEY_ID with No, the ACP document has been forced to use otherName in it's certificates. That's nothing to do with IPsec/IKEv2. But, that that's what IKEv2 will have to deal with. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8XAaAACgkQgItw+93Q 3WWDbwf+Ox6bVwyB9gewn1K+dFyTb2sOKTUNZVuUWV7L7AleuuD0ayk4LpJ8kB40 5eGQzhfOHvgdTv39LSSwW+OWEaG8QFZPEJloIDOOv0tXgsaOliPdvHDNmUdu2wuP 1c3bC7yhj4mgFOpSrjdjXkqzd0S3dMWe7ZUSOLEXx9GAt6LKeD3DzGB+tBdVd4eq lQVxOUIJ/yGeSjvEL4UkF3yJDOAqtlNzZ0yD6MJArEQgujClM6ulSE9/po5aYRTW AyyKbu6jTWKrU7IoOH5gmMBDiIXM7a7MNVtyQliUswnjNFBoOBE3wCEWNrN/nI9x sz33JeBVVMj0FlVzamS7JDMtY1eXfQ== =hGwh -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 22 03:27:05 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B6E3A09DB for ; Wed, 22 Jul 2020 03:27:03 -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 qcCr2tBNwzpg for ; Wed, 22 Jul 2020 03:27:01 -0700 (PDT) Received: from smail.rz.tu-ilmenau.de (smail.rz.tu-ilmenau.de [141.24.186.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B85FF3A09D6 for ; Wed, 22 Jul 2020 03:27:01 -0700 (PDT) Received: from wl-r9-61.rz.tu-ilmenau.de (unknown [141.24.114.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smail.rz.tu-ilmenau.de (Postfix) with ESMTPSA id 808A3580075; Wed, 22 Jul 2020 12:26:59 +0200 (CEST) From: Michael Rossberg Content-Type: multipart/signed; boundary="Apple-Mail=_C6A6C546-E4F3-4D77-B77F-0DBC8B7C4EF4"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 22 Jul 2020 12:26:58 +0200 Message-Id: <023E45E1-B1AA-4042-A8E3-DD7457235BC7@tu-ilmenau.de> To: ipsec@ietf.org X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [IPsec] Teaser for pitch talk at IETF 108 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, 22 Jul 2020 10:27:04 -0000 --Apple-Mail=_C6A6C546-E4F3-4D77-B77F-0DBC8B7C4EF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We have been analyzing issues ESP has in current data-center networks = and came to the conclusion that changes in the protocol could significantly improve = its behavior. Some of results will be presented next Tuesday in a pitch talk at IETF 108. = This mail is just a small teaser, in case some of you wanted to gather some arguments for = the discussion. In particular, we propose the following changes to ESP: * Allow multiple windows per SA to allow for scaling over CPUs, = windows per QoS class & replay protection in multicast groups * 64 bit sequence counters in each header to ease protocol = handling and allow for replay protection in multicast groups * Removing the trailer to ease segment & fragment handling and = alignment * Implicit IVs in spirit of RFC 8750 removing the need for AAD Further details and benchmark results may be found in a paper preprint = [1] and a presentation [2] we held with at the Linux IPsec Workshop. Michael [1] https://telematik.prakinf.tu-ilmenau.de/files/packetformat.pdf [2] https://telematik.prakinf.tu-ilmenau.de/files/VPE.pdf --Apple-Mail=_C6A6C546-E4F3-4D77-B77F-0DBC8B7C4EF4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEE/ZtCXI3ladZ37VLCzADDFAM3dskFAl8YFHIACgkQzADDFAM3 dsmsCA//bD/KoANgtK9zj3ULf+JQ876aGEtkbslLJwbmQtoAFp2CEe8DFgYVT05q 2Ss6//vI7CyKjq36nzstqS1mYlpsjM2/piOq9vs2WFi1w5jeGm3kkP07Ijzv/P4S GGfOWc5FBfOYic3A1A0I6JHKEJIcD7qJPGwvsc4yKrpE2lvHmWnPgr69WvmZaOb4 9ZmIqYDi19QjvigWBPoCJD8rcmhXCkF9LIUb1GTO9BQ0AiYOeemLTfI35r8sgcaz rFid2fo8vPzl8n7acG7oDAa5Ot6vzeW/cK9XBj2OUohteES4bz63UIQ+YXWK3RgV rIS0ubt97iozsZ5PDJdhgkpqz7VnAprHDB4pg4A0uRFIlkw681pTvB36pSkFibjB yM9+UNDGU9mIeqLc5FJ7Z4aWZZYzk/E+k1iXzvUjgHasgFd3W07f6ltwl5PKZ74a B/HInks5MQ0qGUukOpuClK1M9syd4WWSwGYoaVjE9n17AA8ofCvYAvFc2trSax+t IgtddRvlLUP29dHr8erD/Z1U/KpIPcjsEwHsqDBkhOhgNuEnyFyjurjBZ2PfHAOI FH+SYliEThHLBxOfHQe4nGjVfmHZBHy4GX2fXChFw0CWpzyrcsD+t+t9GPK11RUm va7SWQiD+hLuL9JmkdiSarkPktVVemhQN3eTOLROC9hG/Q29RFI= =uUjH -----END PGP SIGNATURE----- --Apple-Mail=_C6A6C546-E4F3-4D77-B77F-0DBC8B7C4EF4-- From nobody Thu Jul 23 04:53:55 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3BB63A07F0; Thu, 23 Jul 2020 04:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 TQfgix-ho3t8; Thu, 23 Jul 2020 04:53:48 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A427B3A0991; Thu, 23 Jul 2020 04:53:41 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 617EC5485D2; Thu, 23 Jul 2020 13:53:36 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 596E8440043; Thu, 23 Jul 2020 13:53:36 +0200 (CEST) Date: Thu, 23 Jul 2020 13:53:36 +0200 From: Toerless Eckert To: Tero Kivinen Cc: Michael Richardson , ipsec@ietf.org, anima@ietf.org Message-ID: <20200723115336.GA30549@faui48f.informatik.uni-erlangen.de> References: <24142.1592760359@localhost> <24309.64229.308771.733097@fireball.acr.fi> <20200626161053.GQ41244@faui48f.informatik.uni-erlangen.de> <24315.37346.143409.46224@fireball.acr.fi> <20200630202812.GF13952@faui48f.informatik.uni-erlangen.de> <24336.33964.354779.953171@fireball.acr.fi> <6871.1595023836@localhost> <24342.51918.664855.708819@fireball.acr.fi> <21070.1595343265@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21070.1595343265@localhost> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [IPsec] Tero: Re: Troubleshooting IPsec peer certs (was: Re: IPsec profile feedback wanted (draft autonomic control) plane) 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, 23 Jul 2020 11:53:51 -0000 On Tue, Jul 21, 2020 at 10:54:25AM -0400, Michael Richardson wrote: > > Sometimes the problem is that there are devices there which do not > > support ECDSA at all, which means you are stuck with RSA for both root > > and EE for all devices. With CERTREQ some parts of the network can > > start use full ECDSA TA and EE and still interoperate with those > > devices which support both and get the "coolness" factor of not using > > RSA at all :-) > > I think that we say that we will tolerate RSA :-) > So you are right: there could be devices which do not do ECDSA on day one, > and in which case, you can't switch the keys at all. I don't think this issue applies to ACP because both RSA and ECC / ECDSA certificates are mandatory. Please check draft-ietf-anima-autonomic-control-plane-27, section 6.1.1. I hope this should be sufficient, if not, then any text fixes welcome. Remember that ACP is not only summetric (no dedicated client/servers), but also greenfield: aka: no need to think about IN THIS REVISION OF ACP about legacy compatibility. IF/WHEN in the future we do provide update/extensions to ACP, THEN we may get into considerations for two generations of nodes talking to each other. > > Other similar cases comes when you merge authorization domains > > together, i.e., two companies merge and they both had their own CAs > > before, and not all devices support both CAs, so you need to pick > > correct certificate one when talking to one or another device. > > Yes, this is an important case. Right now, draft-ietf-anima-autonomic-control-plane-27 does only specify to still send a certificate, even if a CERTREQ was received from the peer, and no certificate would match the TA in the CERTREQ. We discussed how this was for diagnostics. See section 6.7.3.1.2. There is nothing in the current ACP text to say whether or not to send CERTREQ right now. Given how the ACP just provides a refinement profile in section 6.7.3.1.2. on top of RFC8247, and given how RFC8247 does not mention CERTREQ, that leaves is with a "MAY send CERTREQ" (i paraphrase) from RFC7296 section 3.8. The domain merge is also of interest in ACP, so we could add a stronger requirement against CERTREQ, but given how the documents we reference (RFC8247/RFC7296), i am a bit suspicious about doing so. If CERTREQ is so useful in non-ACP use caes, why is there no stronger than MAY in RFC7296 or RFC8247 ? Oversight in those IKEv2 RFCs ? Or are there some downsides coming with it ? I don't think i will add suc a requirement in this ACP spec because it may be necessary to make the merge case work, but it is not sufficient, and the set of components sufficient to support that use case is is beyond the scope of this ACP base spec. To give a hint: We only mandate use of EST, and if i wanted to support a merge, or in general any use case where CERTREQ was useful, then i would need to have nodes that would have two or more certs and CERTREQ is a way to pick one of those multiple certs. And EST to the best of my understandig does not allow to hand out more than one cert to a single node. At least thats what i remember from having asked the quesrtion a few times over the last 5 years. We can still make merge work through extension documents, even without fixing that EST limitation itself through other extensions of ACP, but i think we would want a discuss first whether to rater do that or fix EST. Or someone comes around and tells me this time that EST can be somehow tricked to provide multiple certs to a single node. > >> So, we've been forced to use otherName, and this will cause new code in some > >> of the IKEv2 daemon that we need to use :-( > > > No, you are not forced to use anything. Your ID could be KEY_ID with > > No, the ACP document has been forced to use otherName in it's > certificates. That's nothing to do with IPsec/IKEv2. > But, that that's what IKEv2 will have to deal with. Actually, the ACP text currently says to use ID_IPV6_ADDR, but given how the name of the ACP node is now an otherName, we _could_ signal it via ID_DER_ASN1_GN, but IMHO ID_IPV6_ADDR is better. Cheers Toerless > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec -- --- tte@cs.fau.de From nobody Fri Jul 24 04:33:48 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0654B3A0EF9 for ; Fri, 24 Jul 2020 04:33:46 -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, FREEMAIL_FROM=0.001, 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=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 R45s4nOkU8Uv for ; Fri, 24 Jul 2020 04:33:44 -0700 (PDT) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 A33F43A0EDD for ; Fri, 24 Jul 2020 04:33:44 -0700 (PDT) Received: by mail-il1-x136.google.com with SMTP id p15so6884435ilh.13 for ; Fri, 24 Jul 2020 04:33:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=nJda/zbq2h2PgOB+h0srCsuJfoDBz06X2c4+zn040w0=; b=uXa2iA26atuItkMWhr7kEP1DOY/pA9WpTFigkoFv6EfU0WirM1NqC8HO+HDdzNL9vI JxwCH+5U6v/GWuWeNEGDRDEjM+QnNkqxWK3sX7oH6c/oqyrCUot8ojtbI7aEte8oYozg hUr6xAZbmA5wTxkzMenHFqbMMbOuryB/7Jv+ksVduB6U5gqtHFZIpoQK6gyS2SVdkrtU MS3iiDtF0K1nj2P4PejNT/uzo3JKx6vzViZ49TzLqjRn+tyziRh0XqFawn5m8hQQjyJ8 phio9owWWwCo5A3OI9/bQM/WIVO2XJ3Lq8D2BYHxohuHdSTKzVURTtfaJTBSGdaw7HlE sIZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=nJda/zbq2h2PgOB+h0srCsuJfoDBz06X2c4+zn040w0=; b=L01OjAhzSsfceTAvJmyqvJAd9/9DPjvggqPTHiQRtLXhiGXzKSUoYzO/XIHccpRGnB V6qNpLxS5zTbZIioS8zJKYLatmLzWDL65SDOo6cxMplUwQts9laZ/MDRIo/NRFmg1b+H Zl3I5owSL1OK4WIfoO30nXlYl195dUGLqMzyay+4fVJjc0D4dXd6Ct5cJZnGgYSEgAda spYrL25jog6iZbmhfjfNFixgi/8nQE+ga7keePMQri442743qbsr9zortNHrxaaksmNI r0TP18S3krLWpKOe8BiJnOd1YktJ/XtO4hWdWP7Rnr+b+mWMWE1D/WuJdyMkLpabyllv JLZA== X-Gm-Message-State: AOAM5322PAyVeoDyLgnFKCulSe9hRgp0Dj0WeGl17Ij7loCRSQ28Iwzc sshkUPI6j1rdG62ltRR4oC9l9qbb X-Google-Smtp-Source: ABdhPJzmsltParM/fv0s2G+uE3F+d4pd1MmLPysIJqa3g0IPiGY1i2Y0dyN9BWUxlaT961DStFdWkA== X-Received: by 2002:a92:d64d:: with SMTP id x13mr9799005ilp.287.1595590423802; Fri, 24 Jul 2020 04:33:43 -0700 (PDT) Received: from Wastelandia.local ([2601:401:500:1218:dc53:6252:308f:b7f4]) by smtp.gmail.com with ESMTPSA id g68sm1266461ilh.66.2020.07.24.04.33.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 24 Jul 2020 04:33:43 -0700 (PDT) To: Michael Rossberg , ipsec@ietf.org References: <023E45E1-B1AA-4042-A8E3-DD7457235BC7@tu-ilmenau.de> From: William Allen Simpson Message-ID: Date: Fri, 24 Jul 2020 07:33:42 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <023E45E1-B1AA-4042-A8E3-DD7457235BC7@tu-ilmenau.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [IPsec] Teaser for pitch talk at IETF 108 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, 24 Jul 2020 11:33:46 -0000 I was forwarded this message. As a matter of fact, I've never left the list, but very rarely read it. Speaking as one of the original designers of ESP, I'm delighted that folks are finally catching up to our original design of 25+ years ago! There's no need to rename ESP. The Security Parameters Index was always intended to always be in exactly same place, while the following fields were per transform: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Transform Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ On 7/22/20 6:26 AM, Michael Rossberg wrote: > In particular, we propose the following changes to ESP: > > * Allow multiple windows per SA to allow for scaling over CPUs, windows per QoS > class & replay protection in multicast groups I'll post on this separately. > * 64 bit sequence counters in each header to ease protocol handling and allow for > replay protection in multicast groups ESP as originally specified circa 1994-1995 permitted larger sequence numbers. We had expected all stacks to support them. The size of this field is variable, though for any given Security Association it has a particular known size. ... All conformant implementations MUST correctly process a 64-bit field size. ... As IPsec was originally developed in the SIPP IPng WG, we were advocates of 64-bit alignment of the TCP data. Sadly, a later WG editor removed that facility over my objections. We'd always envisioned that DES would not be the be-all and end-all. But some short-sighted folks restricted the initial RFC published transforms. Heck, they wouldn't even publish triple-DES or DES-XEX. (I was on both of those internet-drafts.) Because of the DES unicity distance, there should never be more than 2^31 packets on the same DES session key. You've been stuck for 25 years with DES-specific transform formats. > * Removing the trailer to ease segment & fragment handling and alignment The trailing payload type was always a poor choice. Caused already perfectly aligned packets to need extra block cipher padding, and even IP fragmentation. But we lost that fight, too. It was a compromise advocated by certain IP stacks of the day that couldn't/wouldn't pass up their stack based upon the SPI. We'd envisioned the SPI to be provisioned on a per socket basis. The payload type and even the port number were to be specified or negotiated by the session key manager. > * Implicit IVs in spirit of RFC 8750 removing the need for AAD > I'll post on this separately. From nobody Fri Jul 24 11:28:23 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311253A1174 for ; Fri, 24 Jul 2020 11:28:21 -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, FREEMAIL_FROM=0.001, 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=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 xr6jE8Jja-vK for ; Fri, 24 Jul 2020 11:28:19 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 C4BA93A1183 for ; Fri, 24 Jul 2020 11:28:19 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id k23so10700641iom.10 for ; Fri, 24 Jul 2020 11:28:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=kVVWXF2hkQne4bLZpzqetyAPn3hJBgc/dB9jtkpIhbU=; b=gQd4JNYIYQQbyt56zURBDv6bzohoNeZLYFwkATG8SV67LXETTB2q+JEkJ2CKoa8DwM HVxdTnsy3TKX97O6YrUs2J7EIa2GyGHKlFI+CNwhA22QAMuqf6/8sqZ2dPjpZ/CByQcj IL2PqbFzh6s87J6k46uXBifZk4mvaDBDZxK/0pbK19VHzzaOON2POz7OQ2JpUVdf9i9h 6ha59p3HLVWSns6DVZP/qYGn179bhaiLc9CetVgBAawmJVWgDrppQetTYFqHPbj8sPbG Pix4ep3Z/BlQC4q9j3QE20ovOhTCp3zL6Xmd2bcrtcD8P2GZM8Bn1SbnWSu3GvThLYno FuPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=kVVWXF2hkQne4bLZpzqetyAPn3hJBgc/dB9jtkpIhbU=; b=bZLjm61ZpEBS4rH8RfJxo1FUgbLq1HCzyqg20PtIctYtyZAjU2d8SgunRcR9Jykr6/ cNX9StnHRkH6kYiadYZ9Ffg/t1iOLSUIx32ZHQLMUroJejfUvfa6TbexjsUWegF950Xp LLkUSJTMlCyP3peGLAbgakfT/2bbK0WDugwVK2luTXN1TQWBBhTHRc7/8KxFoM3JcAXw Ptsx7wwm068Xj1EiKBWmWtxaEaNwICXguDRmCYMg+HX6SfYS8ofZ1QeSPA84YnTaFfID yT0W0XUxIfsMa7UJT0aceQSCtD9g1CpjnmFkRb1UqX2E4n+6M0n/WB39ZsKhvDvW5yBG 6gZw== X-Gm-Message-State: AOAM5306M+u8R9bdgIIucLyAfrZI/2VMKt2X2r58qe+BmquZyPLNCG3C 6COd1h++T0E/AMw4cV6DvudkW9l/ X-Google-Smtp-Source: ABdhPJzaGlogLMeBi53J5S+LKboE0FSfdKvOV3Hs9NuA4nHBAVik+C6ESZFvSbnrcjq3HAuf+m9S/w== X-Received: by 2002:a02:a80c:: with SMTP id f12mr12141637jaj.138.1595615298956; Fri, 24 Jul 2020 11:28:18 -0700 (PDT) Received: from Wastelandia.local ([2601:401:500:1218:e08c:5e77:f6b5:ea13]) by smtp.gmail.com with ESMTPSA id m16sm3558835ili.26.2020.07.24.11.28.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 24 Jul 2020 11:28:18 -0700 (PDT) To: Michael Rossberg , ipsec@ietf.org References: <023E45E1-B1AA-4042-A8E3-DD7457235BC7@tu-ilmenau.de> From: William Allen Simpson Message-ID: <03c7c0d4-698e-bf07-e3af-aaa2eb81221f@gmail.com> Date: Fri, 24 Jul 2020 14:28:17 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <023E45E1-B1AA-4042-A8E3-DD7457235BC7@tu-ilmenau.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [IPsec] multiple windows need multiple SPIs 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, 24 Jul 2020 18:28:21 -0000 No firestorm on the previous message, so here's more fuel.... On 7/22/20 6:26 AM, Michael Rossberg wrote: > * Allow multiple windows per SA to allow for scaling over CPUs, windows per QoS > class & replay protection in multicast groups In the SIPP (IPv6) IPng WG, where we were designing IPsec circa 1993, one of the principal authors was Steve Deering, a/the father of multicast. Some multicast issues were known and discussed at that time. I'm not sure that including a number for the sender is the best way to achieve this goal. We already have the IP sender's address, and in IPv6 the Flow Label, so that's duplicate information. OTOH, I'm very sure that duplicating TCP sliding window functionality is unwise. The proposed field is much too short for large bandwidth-delay products. Perhaps you want it for UDP? However, we were also aware of the need for multiple concurrent SPI flows. We need to keep each CPU working as long as possible on the same data. (When I was at university in the 70s, we had a CDC 6500: 2 main CPUs, and 10 peripheral CPUs. Multi-processing was part of the curriculum, as was OS design, plus a year-long compiler design and implementation class.) Therefore, I'd recommend that IPsec instead implement a block of related SPIs. Each SPI should have its unique session-key as usual, but all would have the same next protocol header and TCP/UDP port associated with the same flow. In the Photuris Extended Attributes internet-draft circa July 1997, we defined the SPI-Block option. Without the overhead of multiple negotiations, a single exchange could generate a list of many related SPIs. You could send on several SPIs concurrently. From nobody Fri Jul 24 11:43:44 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 418843A03EE for ; Fri, 24 Jul 2020 11:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJMuLwLy30be for ; Fri, 24 Jul 2020 11:43:41 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 CF3743A03EA for ; Fri, 24 Jul 2020 11:43:40 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id q5so9171341wru.6 for ; Fri, 24 Jul 2020 11:43:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qSc69P5M5Ud5zUo66sDLx93tn5geXVJi5sDsPs4WCK8=; b=ryM9/dqeuOYL2dTTQAQCRi8Xu75gWtUZ8VExEvnYTcojsmHVVnpULTHZKaXkzuGw+x IBeIcbXDLyWny5hfThRqepIhDVhngx8/R9uGquL0Q7WI7b+EyUX4m0EJWG+WrxISeh4n fvAXM3mrPbh0FDXrSzwIBeDHOFA7KzhziXOq3IKLEE3/tgqksTaWJ5kzjp5OclNP4GFw Chfb8VgVdBvczJCtI/9cDHWp1Doposoh+rXol9roQnXuDFdJCyAK/w7SACsHtYMhWunP fqT9ygz6+4iZnOqBrKceDLMFB613MIYoXPNPe4nyW2FBG3Kdsd+EEKIAhpPAkS6b71gr 6Hxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qSc69P5M5Ud5zUo66sDLx93tn5geXVJi5sDsPs4WCK8=; b=oxB8JrRBKQJwR2icEBNJL7iOOXC6Eionw/fdWCnmWPfd1kF4YGZhD9vxAH+Prbo7xP BVx+A7pirebBuipVwIXE2TzU2aQP7iJCzjws4v94cYJFI7/hvY0zC9raW6EJZCh3jDTu EgargsKgk0FXPtjNlVcWHAhoABfgMd+Xr6x0MpNKG14+yYtgtgRQr5bGU6hN4Jpl+5BU +g/GnxB7PeadqQtetp/o9vutUB4VBsfsYHTsL4z0lnYS0MqkV/xtWiB9njwichtH12/3 1sIE588Bwku9dPa4g66s2V2apQhkZY4reG5o7gASPjM+4ba84kqYlwPC10hH4pUD/9VY 5HRA== X-Gm-Message-State: AOAM530szASIX7vw5gxHr6i7IyNx1D+PJnfTezy1eb3xiPDwE7Zy94T+ laKrc/vpwigiWUc4xxHyLB0= X-Google-Smtp-Source: ABdhPJyT7xPr4/teqMuNC+KDEiO2WQftIk9xoy/zB265hc0d2d1mzWyTZRUsO7J5D2ijaWsRxtd9Vg== X-Received: by 2002:adf:8b1a:: with SMTP id n26mr10330939wra.182.1595616219376; Fri, 24 Jul 2020 11:43:39 -0700 (PDT) Received: from [192.168.1.19] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id j5sm8355310wma.45.2020.07.24.11.43.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Jul 2020 11:43:38 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Yoav Nir In-Reply-To: <023E45E1-B1AA-4042-A8E3-DD7457235BC7@tu-ilmenau.de> Date: Fri, 24 Jul 2020 21:43:36 +0300 Cc: ipsec@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <79E51232-5BEF-4B8C-8772-6305559732AE@gmail.com> References: <023E45E1-B1AA-4042-A8E3-DD7457235BC7@tu-ilmenau.de> To: Michael Rossberg X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [IPsec] Teaser for pitch talk at IETF 108 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, 24 Jul 2020 18:43:42 -0000 Hi, Michael. Thanks for bringing this to the group. > On 22 Jul 2020, at 13:26, Michael Rossberg = wrote: >=20 >=20 > We have been analyzing issues ESP has in current data-center networks = and came to > the conclusion that changes in the protocol could significantly = improve its behavior. Some > of results will be presented next Tuesday in a pitch talk at IETF 108. = This mail is just a > small teaser, in case some of you wanted to gather some arguments for = the discussion. >=20 > In particular, we propose the following changes to ESP: >=20 > * Allow multiple windows per SA to allow for scaling over CPUs, = windows per QoS > class & replay protection in multicast groups > * 64 bit sequence counters in each header to ease protocol = handling and allow for > replay protection in multicast groups > * Removing the trailer to ease segment & fragment handling and = alignment > * Implicit IVs in spirit of RFC 8750 removing the need for AAD >=20 > Further details and benchmark results may be found in a paper preprint = [1] and a > presentation [2] we held with at the Linux IPsec Workshop. RFC 6311 allows multiple members in a cluster of IPsec gateways to have = independent parallel SAs so as to solve the problem of synchronization = and counter re-use among nodes.=20 While the focus there is on different nodes, the synchronization problem = also exists between cores of a single node. There is no reason to think = RFC 6311 could not be adapted to multi-core nodes. So I=E2=80=99m wondering if we really need multi-window logic to scale = over CPUs, or whether it would be simpler to just generate multiple SAs = for multiple CPUs. Yoav (with no hats other than co-author of RFC 6311)=20= From nobody Fri Jul 24 13:42:32 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8C13A0B8B for ; Fri, 24 Jul 2020 13:42:30 -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 kGvy_mkhpgkt for ; Fri, 24 Jul 2020 13:42:27 -0700 (PDT) Received: from smail.rz.tu-ilmenau.de (smail.rz.tu-ilmenau.de [141.24.186.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 827263A0B89 for ; Fri, 24 Jul 2020 13:42:26 -0700 (PDT) Received: from tulum.fritz.box (unknown [77.12.42.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smail.rz.tu-ilmenau.de (Postfix) with ESMTPSA id A770C580075; Fri, 24 Jul 2020 22:42:24 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_09EFCE01-E9F7-4003-AF8E-00AC1A14739D"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Michael Rossberg In-Reply-To: <79E51232-5BEF-4B8C-8772-6305559732AE@gmail.com> Date: Fri, 24 Jul 2020 22:42:23 +0200 Cc: ipsec@ietf.org Message-Id: References: <023E45E1-B1AA-4042-A8E3-DD7457235BC7@tu-ilmenau.de> <79E51232-5BEF-4B8C-8772-6305559732AE@gmail.com> To: Yoav Nir , William Allen Simpson X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [IPsec] Teaser for pitch talk at IETF 108 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, 24 Jul 2020 20:42:31 -0000 --Apple-Mail=_09EFCE01-E9F7-4003-AF8E-00AC1A14739D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Wiliam, Yoav, thanks for the comments, I=E2=80=99ll try to elaborate in a single mail = as you are heading in a similar direction. > RFC 6311 allows multiple members in a cluster of IPsec gateways to = have independent parallel SAs so as to solve the problem of = synchronization and counter re-use among nodes. >=20 > While the focus there is on different nodes, the synchronization = problem also exists between cores of a single node. There is no reason = to think RFC 6311 could not be adapted to multi-core nodes. >=20 > So I=E2=80=99m wondering if we really need multi-window logic to scale = over CPUs, or whether it would be simpler to just generate multiple SAs = for multiple CPUs. If one just has a couple of IPsec gateways happening to be many-core = systems, I totally agree that multiple SAs would be the way to go. IMHO there are still a couple = differences in protocol handling that may be an advantage here and there, but nothing which justifies a = protocol change in the data plane. Now our believe is that the many-core issue is just a special case of a = broader issue. There are more reasons to have unsynchronised replay windows. Let me give a small example: Assume we have tenant with 10,000 VMs in a = data center, all VMs are coupled over VXLANs, which are in turn IPsec encrypted. Each of the = machine may have 16 cores or so. Having SAs for each possible multicast sender being proactively = installed requires 16,000 SAs. If we had 8 potential QoS classes, that problem becomes worse. If another VM pops = up, a group controller needs to push 8*16 SAs to each of the potential receivers, before = communication may take place. Having on-demand replay windows using the same key material, would make = the approach much more scalable - without compromising security (people tend to simply disable = replay protection, use a single SA and split up IV room). We only had one SA for that tenant, and if = there are multicast packets we can direct them to any of our cores for decryption (as long as we do so = consistently). This is most likely a kind of odd view on IPsec, but I am pretty sure = people will do much more L2 in L3 encapsulation and still want security (zero trust is just one of the = buzzwords here). There may be other ways to achieve the same properties, eg creating = entire SAs blocks on demand by deriving them locally from a master secret, but the SPI space will get = exhausted pretty quickly when we leave room for more CPUs, multicast members etc. @William: The 16-bit sender ID is something we already get from = protocols like GDOI to do IV space partitioning (details in https://tools.ietf.org/html/rfc6054). So the = mistake is already there. I hope you have more fuel to get a little more heat (in good sense :) --Apple-Mail=_09EFCE01-E9F7-4003-AF8E-00AC1A14739D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEE/ZtCXI3ladZ37VLCzADDFAM3dskFAl8bR68ACgkQzADDFAM3 dsmTRw/+MSsIciuftJ8AlG/m4q+oNA6TGFAr5DDgWKbBsznaBKHSUBt4uyfQNSST PDVT4tFU1Mmrld3lZCkrGvYnAVKMf1x7kJNY5EaRwv/VsYBJmzj48Y/TyIMU06+K GY5otznO9JCRtGL5A7WoBu9ySASpkMQvAf1KfQkm81LxoqqMlUADoVORX4CDPPUV su1E+AjLT1CpuqvxnkMV3d4CHTR5d1PwjhJq51nhUjXPpmUH5AaLXiXw/ZkoQ2k5 D6AxLWQCoCSuWq/Dwb7GG61l5xd1nLuv7lNiKm91paL1XPS1QHE2+3JF2MpNVCoq x69OerJjAn+2GEnJ9N7Hf8ZSV8QgY5QrocmQi90+MXziivP90ccIa5wWyqj7kHBS FhsDeKVyGCzvtuiWqD2rQZdHRQv1XOC5OV4qzID3830tt3u+DTxE2xLgZWmnRMeQ uCTV7zUWHJEE+GMSQ/dI0BhDqs4O3Z98obT89BIqhgw+8/V/w36qZKlLPa2sA1zq yXI5TviOXY85DO+8+G9hj85lawCT9s4j8ezrC7lriad5uiGeB/QRYcGnwcGHB0iL TeX6aWLXP6L9XLI1/CE7JBabg8XVNnFaW5mLS0BkXE3JKTDmkx7c7H1jEQ2JFf6j HdL/eoBNQk6N8JJNMwGAVZJVCydExBhn1GTym7ujyOy+UPTd4SE= =15n1 -----END PGP SIGNATURE----- --Apple-Mail=_09EFCE01-E9F7-4003-AF8E-00AC1A14739D-- From nobody Sat Jul 25 08:24:07 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D57C3A0AC5 for ; Sat, 25 Jul 2020 08:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 P7GJwsoXEQCw for ; Sat, 25 Jul 2020 08:24:03 -0700 (PDT) Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) (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 B5D603A0ABC for ; Sat, 25 Jul 2020 08:24:03 -0700 (PDT) Received: by mail-wr1-x444.google.com with SMTP id r2so5759581wrs.8 for ; Sat, 25 Jul 2020 08:24:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=egNWdd26PlvGhsv4Vj4EWEIpnas04yT/ik1bxWwtEqo=; b=PGHc5GpE1ZWoELWIGnnhhmsueNDPgaHx9GRZ8OTxDLqYvXkMj8Qg1MYxRC9vcuZ8FE pKbk2YpY/shLC8kpT4LNsCX/5cOfbbQdezsAuXbhmsbKpxuD3Xjo+LF0BJON2kEHagzn +LcGgou4m2t4JvkZJVxjLrh+z0v4sM/456NNUELjrCVLr7qU+xBJj3EwDLOO9k2rgQ1h 2MJUsvgJfRFZcg9D99Ja8nBE/EnReq9uWLpHEBsZ8DLjlUV84j6rjFxz5FY5NzrUyxOt GahQu8QsdWvg7s1xSoWMxy6Ge8wy2cLp92Vk8DQZcEcKmz6CLt6LiMzXbfzIUWuAcx2+ Ao1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=egNWdd26PlvGhsv4Vj4EWEIpnas04yT/ik1bxWwtEqo=; b=U9kYMKT1Un53qpOM4I6ZWJE/JgVXeA9FO5UBuhqyMpnseQnSlM2iU2RkuHXm9OGy1D pdZB4scOWx1lxsk1GMmGq3K1V8QklLUfaq5v6KWnin6dGKBIUQ7kgoLMcWq0lhJhoKQW 5op/aBj/NZn3g8RlQ6dZyl7g2/MwlabEwhR0ZILKlxtgt9bb2cZeI2jh+rhkdTMtysEL NAuEbVjiaPi7+98CO2VRSRoPv+oMczGFDWANaoG4v61ao8V5gSQdNhcmNzy+WBTw6y0q LwEKsPofv5WyvZtcFVPOH0yEhVWo8UN5yX3peb2LrTB+ehtwh7uLsSjF7LCyImGBOlIo GNBg== X-Gm-Message-State: AOAM532Lgw2vy2scsQpA8UvcQOElwhYDOSmtkUPpO8yNxrqNWVAJ5v/r 4YCnuFjDnAnfeL9ToQA6q3k= X-Google-Smtp-Source: ABdhPJwPmNZgjkgs4wu9zYDVkJbmZr7CehNR71WvFn/zI8JhFxQgTtRGYd7x845nCMQUsWtdvJ/pRw== X-Received: by 2002:a5d:484d:: with SMTP id n13mr13164366wrs.297.1595690642046; Sat, 25 Jul 2020 08:24:02 -0700 (PDT) Received: from [192.168.1.19] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id o30sm5601703wra.67.2020.07.25.08.24.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Jul 2020 08:24:00 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Yoav Nir In-Reply-To: Date: Sat, 25 Jul 2020 18:23:59 +0300 Cc: William Allen Simpson , ipsec@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <023E45E1-B1AA-4042-A8E3-DD7457235BC7@tu-ilmenau.de> <79E51232-5BEF-4B8C-8772-6305559732AE@gmail.com> To: Michael Rossberg X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [IPsec] Teaser for pitch talk at IETF 108 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2020 15:24:06 -0000 > On 24 Jul 2020, at 23:42, Michael Rossberg = wrote: >=20 > Wiliam, Yoav, >=20 > thanks for the comments, I=E2=80=99ll try to elaborate in a single = mail as you are heading in a similar direction. >=20 >> RFC 6311 allows multiple members in a cluster of IPsec gateways to = have independent parallel SAs so as to solve the problem of = synchronization and counter re-use among nodes. >>=20 >> While the focus there is on different nodes, the synchronization = problem also exists between cores of a single node. There is no reason = to think RFC 6311 could not be adapted to multi-core nodes. >>=20 >> So I=E2=80=99m wondering if we really need multi-window logic to = scale over CPUs, or whether it would be simpler to just generate = multiple SAs for multiple CPUs. >=20 > If one just has a couple of IPsec gateways happening to be many-core = systems, I totally agree that > multiple SAs would be the way to go. IMHO there are still a couple = differences in protocol handling > that may be an advantage here and there, but nothing which justifies a = protocol change in the data > plane. >=20 > Now our believe is that the many-core issue is just a special case of = a broader issue. There are more > reasons to have unsynchronised replay windows. Right. And my question is, why not have multiple SAs instead of multiple = windows within an SA. The advantage of multiple SAs is that you don=E2=80=99t really need to = change the other side of the IPsec connection (especially if the peer = already supports 6311). So if you have 30 cluster members, or 30 CPUs, = or 30 virtual LANs, or 30 QoS classes, you can generate 30 SAs rather = than 30 windows within 1 SA. An SA is rather cheap: It requires a value out of a 32-bit space. It = requires at a minimum saving the key and current counter. Usually also a = 64-bit replay bitmap at the receiver. Add metadata and we=E2=80=99re = talking about a few dozen bytes. Add an expanded key for performance, = and we=E2=80=99re still under a kilobyte.=20 I=E2=80=99m not saying it=E2=80=99s a better design, but a new design = should come with an explanation of why it=E2=80=99s better. Yoav= From nobody Sat Jul 25 10:59:14 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475C73A02BE for ; Sat, 25 Jul 2020 10:59:12 -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, NICE_REPLY_A=-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 lKctygvq5Iqc for ; Sat, 25 Jul 2020 10:59:11 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 DE69C3A0044 for ; Sat, 25 Jul 2020 10:59:10 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id i4so12986221iov.11 for ; Sat, 25 Jul 2020 10:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=JLgyl/AbdnFmZHuo/Js4TRE4YIYgFnZpUWPmj7bL/II=; b=c0A1qRkP9UQDfIY08S3vvgOFZTFO/yoi/AE0J0/v0sVu2N7RAHYWom8288RtA0tn1W vDOjR07mTqsjjHpi/3UERtC5/bqhcRsqybx1wnXcuR8qJ8j1Dnc0K5qqd92lnqrgqyoX fGvmbCkMBPM3F9wFKVxUrEOtt/Rv8wxWpA5mOHsRyRYppfsbJxddeR4mB7gY4bP5DLJi ksTbMmZ6Aybc3PR3YZhucKflpoCFFbX3af4SrFSNlMivW3v/YbRyZhEeeIZw3/RGILaA wBh6/5ZllGN5h+knRf4KiYUnSL3fyQlWatTiIpMsvyvSYDLFkzEP1xWZ5Da5jmagVRvu Ak5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=JLgyl/AbdnFmZHuo/Js4TRE4YIYgFnZpUWPmj7bL/II=; b=mnoVktf7kRGHVSh5ZY40X4LqEilsdsgZFTEwiQf54YJ9UH0t38jwm3MzZNdtJkrHpu tvWFL5wHijOtDypve/LZKFGdsHOPJaGJjhPFqEliALlKLd3gn7CHJSQjHyg23LlYJcb/ FDNVyLWpNc0kQ2mpVNjo6p/v8mnbb0arWUzNJbUGX+kNDuIONgD+m2qdEgiu/6lSPk6p /PQ2vVv2jhvs6422sDEOa+Wu9SN9pnClJ+RKu6bysLIulkOe7lybLdOwmOIzQ+p+5KlB +f/6/amZkgxjI40wyxJjVmRD+qBoD0mHxPsHyrBEUkxbNJO1eKw/kHHZXnVW8KVCvqei NXyg== X-Gm-Message-State: AOAM533MQgv/fQAxFBTa79sEhGDee0hQrpVrdQC8/xxbHobUnE6LE61P uPKA+WC5QyzfCmPcx+roXXmRvTbD X-Google-Smtp-Source: ABdhPJx+VoJtiRetnkxvu1ypKXqSybZJUuI81JRDqyuhuDm7beoI0b9sgChpmtBGVSSBrY8SYxyK9A== X-Received: by 2002:a6b:c504:: with SMTP id v4mr338659iof.20.1595699949991; Sat, 25 Jul 2020 10:59:09 -0700 (PDT) Received: from Wastelandia.local ([2601:401:500:1218:143a:876:facf:5c3]) by smtp.gmail.com with ESMTPSA id s85sm799210ilk.77.2020.07.25.10.59.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 25 Jul 2020 10:59:09 -0700 (PDT) To: Michael Rossberg Cc: ipsec@ietf.org References: <023E45E1-B1AA-4042-A8E3-DD7457235BC7@tu-ilmenau.de> <79E51232-5BEF-4B8C-8772-6305559732AE@gmail.com> From: William Allen Simpson Message-ID: <1382fcfe-db71-f6be-a96e-136f1d888769@gmail.com> Date: Sat, 25 Jul 2020 13:59:08 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [IPsec] Teaser for pitch talk at IETF 108 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2020 17:59:12 -0000 On 7/24/20 4:42 PM, Michael Rossberg wrote: > @William: The 16-bit sender ID is something we already get from protocols like GDOI to do IV space > partitioning (details in https://tools.ietf.org/html/rfc6054). So the mistake is already there. > My memory was 8 bits, ludicrously small. Reading more carefully, they illustrated 8 bits, but also specified 12 and 16 bits. But this is an opportunity to do better. Let's not repeat mistakes. In my own area of experience, RDMA for large storage clusters across multiple data centers, you are going to run out quickly. Use existing IP Source header fields to build the IV. Add and xor are sufficiently fast. From nobody Sun Jul 26 11:10:51 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19753A126E for ; Sun, 26 Jul 2020 11:10:49 -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 ziek-QVzAl2L for ; Sun, 26 Jul 2020 11:10:48 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C0193A0F72 for ; Sun, 26 Jul 2020 11:10:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 1BE69389E1 for ; Sun, 26 Jul 2020 13:50:17 -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 bVnUhdOYQ8DD for ; Sun, 26 Jul 2020 13:50:16 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5E9DB389E0 for ; Sun, 26 Jul 2020 13:50:16 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4C9E64CC for ; Sun, 26 Jul 2020 14:10:46 -0400 (EDT) From: Michael Richardson To: ipsec@ietf.org In-Reply-To: <03c7c0d4-698e-bf07-e3af-aaa2eb81221f@gmail.com> References: <023E45E1-B1AA-4042-A8E3-DD7457235BC7@tu-ilmenau.de> <03c7c0d4-698e-bf07-e3af-aaa2eb81221f@gmail.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] multiple windows need multiple SPIs 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, 26 Jul 2020 18:10:50 -0000 --=-=-= Content-Type: text/plain William Allen Simpson wrote: > Therefore, I'd recommend that IPsec instead implement a block of related SPIs. > Each SPI should have its unique session-key as usual, but all would have the > same next protocol header and TCP/UDP port associated with the same flow. I agree with this model. And I think that IKEv2 makes this significantly easier than IKEv1 did. We are still relearning Photuris. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8dxyUACgkQgItw+93Q 3WW/Kwf7BncZd7QvWow7O560zg7qf0V2vW2K3i/C37uCFXzKPYWlxuIO9tIqODTX hXuAmnERb7sNJ1oayKPLA9PHm/rYgmE6Js7Ni8sYAgx9O+NCePiIzfT48vO/B27N gtinXLh8PNuM8IAaP7R3SYbu7LeCuInonW2v4Dq6b4sxBZtHrhI5N+rlbyXnfshr ay+utqpLY02JXmrsfYYxH+h5NeeqH8tymNa/HJcdfh5B8xkfzH3ZhkzyAZ0qAs4t EgmRN+HQPnzH1Uhx+ZIeVcDDlU04qIrv3wdJbOZtf4OWMGm3lq0UPSUQPH6ArhA4 KPBKO2/LrpjIKTd5f37I800HQlE56Q== =Wqmm -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 28 01:13:40 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475C63A0824 for ; Tue, 28 Jul 2020 01:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 484QtsOmECIk for ; Tue, 28 Jul 2020 01:13:36 -0700 (PDT) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 3BEAF3A081F for ; Tue, 28 Jul 2020 01:13:36 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id d2so4886206lfj.1 for ; Tue, 28 Jul 2020 01:13:36 -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=peD9+cyWSVPwYKBk/d8cvsFddwM+iHotJQzloEWFBDI=; b=TI2jKmMT6Is5QvJzPo6kHNKAHA2jBO9do2cS6s/8/LBKSSbSeKkdvaSccNsxb8PkPv bByDRhPO8kg6tjsw09eKXRZ/ZAaawPMbTtgZun4+v4+OfQsrNK/7DCVMRBG+Gcmg9IiZ 0gw6LYh6TcFR3yqHxiCIQbHHez5wCtvr5a2TJWcyWynP2L/F6dy2RYN8c+8ma41EaKu6 LYpCMMnuXW5tDlP8S3Uo4s220RoYcVpK8gv+6LPTvQbiYHPw5znpO5ivTy1MIlSOZinV F+ns1MAVggtEi8JKT0fFyn4igh9IkyNFUnXIa6P4DhKNnNqIr5W3q/jbKTh1cTYP660S DBtg== 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=peD9+cyWSVPwYKBk/d8cvsFddwM+iHotJQzloEWFBDI=; b=p9LSZ6G3+lLc54AMoIcZgF77lPpTXKB2C0wZirkb6iKUfXLKPIuQNJKhOCQqbByG1B un3O3jJuwD8dF5IfsrTh1fpXYFsF66CA8S3pyyKgfEIJ5zuaGB8SerHgkPmhpKhhOBcD zOteEgrRyy5vbWz8fjCVZozyCi3+bu8M5Qf0IvICbrKiwRoc65+ehKuOZ2cHAK940/7G 0hDOwfI1y8OnhWdG+R/RffL7IHiv1yCF5lNbvBbwmUxgQJt/sRz/Lqsto2qdo6WFysII dYoevmYnMnta61pkQ2yEKvNw2vQILk0UeUnZr1U3nR699X7jw+Itepl/YaF0fHC+rXm2 AthA== X-Gm-Message-State: AOAM533NVrHvZHqjExd8GHxlBx7oYjLIfYvvi6Sa7nNfQ75Yf7xydlHK +BVIEabejbIAujY/0g6H5GeIL4ts X-Google-Smtp-Source: ABdhPJyrxK9YcpnU8jQjlgp77u5CeRPXM0PceSooZ8RJ9NJneYHYardLH4EXy7CsO9erkU3H+GeCtA== X-Received: by 2002:a19:c894:: with SMTP id y142mr13162878lff.74.1595924013788; Tue, 28 Jul 2020 01:13:33 -0700 (PDT) Received: from buildpc ([82.138.51.3]) by smtp.gmail.com with ESMTPSA id m4sm2822980ljo.70.2020.07.28.01.13.32 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jul 2020 01:13:32 -0700 (PDT) From: "Valery Smyslov" To: "'Michael Rossberg'" , References: <023E45E1-B1AA-4042-A8E3-DD7457235BC7@tu-ilmenau.de> In-Reply-To: <023E45E1-B1AA-4042-A8E3-DD7457235BC7@tu-ilmenau.de> Date: Tue, 28 Jul 2020 11:13:33 +0300 Message-ID: <0fd501d664b6$fcc8c590$f65a50b0$@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: AQLb8KjJ82/eUG4ib/oDCzGyVFFVxqcRcapA Content-Language: ru Archived-At: Subject: Re: [IPsec] Teaser for pitch talk at IETF 108 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, 28 Jul 2020 08:13:39 -0000 Hi, a few thoughts about this proposal. > We have been analyzing issues ESP has in current data-center networks and came to > the conclusion that changes in the protocol could significantly improve its behavior. Some > of results will be presented next Tuesday in a pitch talk at IETF 108. This mail is just a > small teaser, in case some of you wanted to gather some arguments for the discussion. > > In particular, we propose the following changes to ESP: > > * Allow multiple windows per SA to allow for scaling over CPUs, windows per QoS > class & replay protection in multicast groups An ability to have multiple windows per SA is an interesting idea. However, in most cases the same result can be achieved with several parallel ESP SAs with the same traffic selectors. Comparing with this proposal: 1. Several parallel ESP SAs require more resources to set up. On the other hand I don't think it really matters (2 short IKE messages per SA is not a big deal, especially if no PFS is used and we are going to transmit millions of ESP packets then). 2. Several parallel ESP SAs require more resources in the kernel. This is true. 3. If multiple windows are used for several QoS classes, then this proposal won't work in case of TCP encapsulation, while several ESP SAs will (if we have several IKE SAs too). Having replay protection in case of multicast is a feature that is not currently available in ESP. However, it's easy to add this feature (with the limitation that it only will be available if counter mode ciphers are used) by simply letting all GMs know the number of SID bits, so that they can guess Sender ID from the IV. It's very simple modification of G-IKEv2. Having said this, I think that the replay protection for multicast is not a feature that is absolutely needed. Multicast is performed over UDP, so application protocols have to deal with packet replication and loss in any case (when they are used without IPsec protection). So, while a nice feature to have, I don't think it's absolutely necessary and if one needed, it can be achieved without any modification to ESP with the same limitations as the proposed solution. > * 64 bit sequence counters in each header to ease protocol handling and allow for > replay protection in multicast groups This would simplify replay protection logic on receiver, but will waste 4 bytes on the wire for unicast SAs. I agree that ESN with ESP would not be available for multicast even if the above mentioned solution (letting GMs know SID) is implemented. But I'm still not convinced we need it. > * Removing the trailer to ease segment & fragment handling and alignment I was told by Linux kernel people that having trailer in ESP is a headache for them. However, this simplification has its cost: 1. Ciphers that require padding cannot be used. I admit that CBC and the like are out of fashion today, but I don't know which cipher modes will be in fashion tomorrow and what requirement for padding they will have. 2. No Next Header field eliminates transport mode (BTW, widely used for multicast!) and makes it difficult to implement TFC (you can add TFC padding, but you can't send dummy packets and you can't use IPTFS) > * Implicit IVs in spirit of RFC 8750 removing the need for AAD I don't consider removing AAD is a benefit, since all the AEAD schemes I'm aware of allow to have AAD. On the other hand, implicit IV is only applicable to some transforms. I'm not only talking about non counter-based AEAD ciphers, (like CBC), but even for counter-based AEAD a situation is possible when there is a need for IV to be somehow structured and not be a plain counter (e.g if you implement key trees). > Further details and benchmark results may be found in a paper preprint [1] and a > presentation [2] we held with at the Linux IPsec Workshop. A few more considerations. It seems that performance of this proposal depends on ICV size for the plaintext to be properly aligned. If ICV is 16 bytes, then plaintext is ideally aligned on 32 bytes, but if one use 12 byes ICV (e.g. ENCR_AES_GCM_12) then the plaintext is aligned on 4 bytes, that is even worse than ESP, where it is for most AEAD transforms aligned on 16 bytes. Since this proposal allows only tunnel mode, it will have larger overhead for small packets. This is partially compensated by having IV to be implicit... And about security. In order to have IV combined with ESN and sub-windows identifiers this proposal removes secret salt from the nonce. This may have impact on security. I'm not a cryptographer, but I believe the impact is not negligible. On the last CFRG session a draft draft-wood-cfrg-aead-limits was discussed that calculates limits of data to be safely encrypted by various AEAD ciphers. The authors claimed that having secret salt in the nonce increases this limits in case of multi-user attacks and that the results in the draft are calculated for this case. If plain AEAD ciphers (with no secret salt) are used the limits are lower. So, on one hand this proposal makes it possible to transfer larger amount of data with a single key (because you can combine all the traffic from different QoS classes and all the CPU cores into one SA, no need to have several ESP SAs). On the other hand it simultaneously decreases the limit of data that can be safely protected with a single key. I think that it's an interesting work, but I don't think it is a candidate for ESP replacement. The main problems with it (as I see it from my corner) is that it is not generic enough: it is optimized for small number of crypto transforms and use cases. Regards, Valery. > Michael > > > [1] https://telematik.prakinf.tu-ilmenau.de/files/packetformat.pdf > [2] https://telematik.prakinf.tu-ilmenau.de/files/VPE.pdf From nobody Tue Jul 28 01:26:59 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9CAB3A0881 for ; Tue, 28 Jul 2020 01:26:56 -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 BbahDjCQaNlr for ; Tue, 28 Jul 2020 01:26:55 -0700 (PDT) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 234BB3A086F for ; Tue, 28 Jul 2020 01:26:55 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id j22so4636330lfm.2 for ; Tue, 28 Jul 2020 01:26:55 -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=0vD/3zx0IEIWMXjHC82tj8ivnf0WAxJlcARVCKPaPcg=; b=HEsH0FxjQjILeLtFpZYYVHhRujYvlqeVGa8+ga4G63NK5KrlhYdQ0jhz1ofNZLqdnI FDhb7AOi240ir0t7nl6pBS7xDP+gP8HuqkHY2cNk7Yw/QDsrozF8Z5sU36U6AXvtGYld AItNaDByMEdTnKFXbFnIRRhfJZWLqIVnuImESWmNXZE5NOFKTSLpoR1tWodt3gzTO1Td Mkk2Cw4Hkzv87gBqN+pdyLChUBDlq1qPTQr0g1W1SGqrJJWQfbtXv2CE4oDGSW+y2rr0 RtfTPKI9NCT5Rax7nueMtlB0XxfZjM9pFDRFunswRT4sAX3IcXw1zSOPacKd/2WzCPNs smRw== 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=0vD/3zx0IEIWMXjHC82tj8ivnf0WAxJlcARVCKPaPcg=; b=nIpQn8ZsudtyhDNbggQz0MIJNXRx4xOHM39+mPqi/o1q3tDaHZSN8p0nmNgUcU3pzR m+BuPrY9MTvhVCx/bcFvbXFeKsr68bKkDtrI2t40lK/Endu2PqTsnEvObiyx7pDvHsWM Q0q+r7+dkT/gz4cJmd9weie2RR22WcEdF19mbJ3+zrawxqy9Q/ZfmCBnr68L88TUG1kB W1W3rdFRHsqLnMC+5Vqo+B8H+u9XXFIkUMZCZYlAbVjElu5ErPajaLW8da2Hp31JlHFW weKlZ1x7ATwoc2hmU0/YhjFGsgGGpeqpUTA7TfCzmidxuxFUqQoG/oVxdkkgWxXFTI77 +M8Q== X-Gm-Message-State: AOAM533ywFkl+2eBgoh9wMs2zOJdF4Uv7KkukBd6wkDhGRVyvAN7m4oX JCCitgg/GtaFILk4uVWIY8CV9+R5 X-Google-Smtp-Source: ABdhPJyps364u/B+i1tFfBnkFIP3fdIkuzlT2aiPGvyYDftcu9L4Ipse7xE8smgd/+Jq+Oez1M3D5A== X-Received: by 2002:a19:428c:: with SMTP id p134mr13957135lfa.70.1595924813186; Tue, 28 Jul 2020 01:26:53 -0700 (PDT) Received: from buildpc ([82.138.51.3]) by smtp.gmail.com with ESMTPSA id k8sm2825517lji.13.2020.07.28.01.26.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jul 2020 01:26:52 -0700 (PDT) From: "Valery Smyslov" To: "'Michael Rossberg'" , "'Yoav Nir'" , "'William Allen Simpson'" Cc: References: <023E45E1-B1AA-4042-A8E3-DD7457235BC7@tu-ilmenau.de> <79E51232-5BEF-4B8C-8772-6305559732AE@gmail.com> In-Reply-To: Date: Tue, 28 Jul 2020 11:26:53 +0300 Message-ID: <0fd601d664b8$d955fea0$8c01fbe0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLb8KjJ82/eUG4ib/oDCzGyVFFVxgG4NAWZAm+Qbvqm8E/gcA== Content-Language: ru Archived-At: Subject: Re: [IPsec] Teaser for pitch talk at IETF 108 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, 28 Jul 2020 08:26:57 -0000 Hi, > @William: The 16-bit sender ID is something we already get from protocols like GDOI to do IV space > partitioning (details in https://tools.ietf.org/html/rfc6054). So the mistake is already there. RFC 6054 doesn't limit the number of SID bits to 16, it only says that 8, 12 and 16 bits MUST be supported. You may use longer values... Regards, Valery. From nobody Tue Jul 28 03:27:53 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 119773A0A9E for ; Tue, 28 Jul 2020 03:27:52 -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 O5f5avP6Y_KG for ; Tue, 28 Jul 2020 03:27:50 -0700 (PDT) Received: from smail.rz.tu-ilmenau.de (smail.rz.tu-ilmenau.de [141.24.186.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B4DE3A0A9D for ; Tue, 28 Jul 2020 03:27:49 -0700 (PDT) Received: from [192.168.2.109] (unknown [217.230.190.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smail.rz.tu-ilmenau.de (Postfix) with ESMTPSA id A4F93580061; Tue, 28 Jul 2020 12:27:47 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_ECE27D37-DF3D-48A0-8328-8E93B90B942E"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Michael Rossberg In-Reply-To: Date: Tue, 28 Jul 2020 12:27:46 +0200 Cc: William Allen Simpson , ipsec@ietf.org Message-Id: References: <023E45E1-B1AA-4042-A8E3-DD7457235BC7@tu-ilmenau.de> <79E51232-5BEF-4B8C-8772-6305559732AE@gmail.com> To: Yoav Nir X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [IPsec] Teaser for pitch talk at IETF 108 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, 28 Jul 2020 10:27:52 -0000 --Apple-Mail=_ECE27D37-DF3D-48A0-8328-8E93B90B942E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >>> RFC 6311 allows multiple members in a cluster of IPsec gateways to = have independent parallel SAs so as to solve the problem of = synchronization and counter re-use among nodes. >>>=20 >>> While the focus there is on different nodes, the synchronization = problem also exists between cores of a single node. There is no reason = to think RFC 6311 could not be adapted to multi-core nodes. >>>=20 >>> So I=E2=80=99m wondering if we really need multi-window logic to = scale over CPUs, or whether it would be simpler to just generate = multiple SAs for multiple CPUs. >>=20 >> If one just has a couple of IPsec gateways happening to be many-core = systems, I totally agree that >> multiple SAs would be the way to go. IMHO there are still a couple = differences in protocol handling >> that may be an advantage here and there, but nothing which justifies = a protocol change in the data >> plane. >>=20 >> Now our believe is that the many-core issue is just a special case of = a broader issue. There are more >> reasons to have unsynchronised replay windows. >=20 > Right. And my question is, why not have multiple SAs instead of = multiple windows within an SA. >=20 > The advantage of multiple SAs is that you don=E2=80=99t really need to = change the other side of the IPsec connection (especially if the peer = already supports 6311). So if you have 30 cluster members, or 30 CPUs, = or 30 virtual LANs, or 30 QoS classes, you can generate 30 SAs rather = than 30 windows within 1 SA. >=20 > An SA is rather cheap: It requires a value out of a 32-bit space. It = requires at a minimum saving the key and current counter. Usually also a = 64-bit replay bitmap at the receiver. Add metadata and we=E2=80=99re = talking about a few dozen bytes. Add an expanded key for performance, = and we=E2=80=99re still under a kilobyte. >=20 > I=E2=80=99m not saying it=E2=80=99s a better design, but a new design = should come with an explanation of why it=E2=80=99s better. A key advantage of the replay window approach is that there is no need = to setup every window proactively. That is there is no overhead at all as long as a replay window is not = used. In a multicast environment it would require reliably pushing a key to every possible sender, which may = become a fairly large group. That is IMHO a non-negligible overhead. We could also solve this by adding some kind of associated SA that is = automatically set up on-demand, but then we need to subdivide the SPI space somehow. As Valery and William are = =E2=80=9Cunhappy" with only 16-bit sender IDs (perhaps for a good reason), we would require larger SPI fields... --Apple-Mail=_ECE27D37-DF3D-48A0-8328-8E93B90B942E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEE/ZtCXI3ladZ37VLCzADDFAM3dskFAl8f/aIACgkQzADDFAM3 dsk7eg/9EzO+BQ9OTgIGDfXh+e8VMwVBAHU6Ix2Qtyip4EZITPR8m1GSDo5zFshI 60/fxJhcy39VWZkX5KA61t0OMcGWMicKwOXsOT16sTP4VzpENYDS34DMbxRHpQmE 8GAXdYAFRM5QKROdVR78uIfXVfVnFe/vUEFWTeaR1OSzFO7jooN9ZqQ/4eQEgMlj S1z3W6hIcVj43UGSutkjm9RkfhqE9upe9mT4cVA39dvsXd43X7BE6X5/YIsRWrYQ Qwuf8OFPVb8hCsCHyd5VA7ZUT156sHYPSml6XWNjZ66Xj9kQ1vSKM+fYeYAdGgij GBd+lK5R0QK0YGQQxN7Nm13e72GSshZQP/ovaIGuOaTRZXfel+HLxY8ISpoAWtcA YbZ/bNSCs7e/oFzipFKo5LzsOdKtm+8YEUtS6qVE7hjtLGQ4gCUPu4YacTzeZCa6 ArezS62uTrnreUb9+dyjMasF4QxEfvDCHJ8VX5SfgIXvypEQaWQYBmKMq33wXHq4 qofgz/3rKYMj+hldKXJNQGQ6r5uei7DfsdLGcKUcoEtJQmKSyyAPdb57gXPOPSM9 m37larKNyS1ydpm+coCY7u9/yR73KfLQY6DnD1wl2HevMcOOMyG8WfuVsodHCFx9 vj3Uk3Et0W1xsBgcTR8iXPse9l0axCd95Yz8RQ3mCgUbdBFnnco= =lFWz -----END PGP SIGNATURE----- --Apple-Mail=_ECE27D37-DF3D-48A0-8328-8E93B90B942E-- From nobody Tue Jul 28 03:31:11 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A513A0AA8 for ; Tue, 28 Jul 2020 03:31:10 -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 bjR5LsU-TohU for ; Tue, 28 Jul 2020 03:31:08 -0700 (PDT) Received: from smail.rz.tu-ilmenau.de (smail.rz.tu-ilmenau.de [141.24.186.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67A2E3A0AA0 for ; Tue, 28 Jul 2020 03:31:08 -0700 (PDT) Received: from [192.168.2.109] (unknown [217.230.190.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smail.rz.tu-ilmenau.de (Postfix) with ESMTPSA id C168C580061; Tue, 28 Jul 2020 12:31:06 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_884E323C-FE30-42F4-B7BA-EC40E1B7EE6D"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Michael Rossberg In-Reply-To: <1382fcfe-db71-f6be-a96e-136f1d888769@gmail.com> Date: Tue, 28 Jul 2020 12:31:06 +0200 Cc: ipsec@ietf.org Message-Id: References: <023E45E1-B1AA-4042-A8E3-DD7457235BC7@tu-ilmenau.de> <79E51232-5BEF-4B8C-8772-6305559732AE@gmail.com> <1382fcfe-db71-f6be-a96e-136f1d888769@gmail.com> To: William Allen Simpson X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [IPsec] Teaser for pitch talk at IETF 108 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, 28 Jul 2020 10:31:11 -0000 --Apple-Mail=_884E323C-FE30-42F4-B7BA-EC40E1B7EE6D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> @William: The 16-bit sender ID is something we already get from = protocols like GDOI to do IV space >> partitioning (details in https://tools.ietf.org/html/rfc6054). So the = mistake is already there. > My memory was 8 bits, ludicrously small. Reading more carefully, they > illustrated 8 bits, but also specified 12 and 16 bits. >=20 > But this is an opportunity to do better. Let's not repeat mistakes. >=20 > In my own area of experience, RDMA for large storage clusters across = multiple > data centers, you are going to run out quickly. Use existing IP = Source header > fields to build the IV. Add and xor are sufficiently fast. While I love the approach, there would be a significant chance for a = collision in the rather small IV space. Thus, modern ciphers would break. Due to IPv6 = addresses being much larger than current IVs, we have to do some explicit = numbering, if we want to use the same key. --Apple-Mail=_884E323C-FE30-42F4-B7BA-EC40E1B7EE6D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEE/ZtCXI3ladZ37VLCzADDFAM3dskFAl8f/moACgkQzADDFAM3 dsmXOA/+No4l4+70gAOaBsHne7zh9/b9ByN20Ux6ADq0Fm+l0y/qLaR1q4ZN6SxQ VWrdyztW5eU6qhSQ0lqcix9S5DE2z33CxI+j0L+vtyMB6wi8a4VYvuLkgro6Jk2b RyXZCz0iBmXiaapdujnnZhzQghI1NXm6gMMJth4VfZtS0TFhPjcfc+OtkOzEgEgZ CRA9FfWkeMUOYbahtbExS0na/4IEgEE3VRapxedvXxuz/WnGc8m1utS7E7I81HKZ ZM3WSH00XXIIiMvi9m+lZ0Y20NE8Wv3UG4/960rZ1VrCbe9Gnlm0YuGnrzgA/6WX CL1akSFhOgZANx51kStlAEiIQ6Q/ruPa0OtcXsffSZBIEX2dDFnjSCtG/4nP31II gpWEhags9iN4IJJf6sFchjkNUZWDcDzMpTnFSakHQmBzMd2zlAvQ1qW7Zh93jrAV EW1FmfGKMYhKrIlJKyJB2g7LDfjj0juFHJYKxZ/4a40ehIRCgDK0YfRGHJNhTvY2 nFkwFGPaJtM7MAYISgyAN8IakkGWTG8yWhQbxZS7yU/dOPrZPzrgneMb2X+26f6A p9nA5hYDBWy7W4nE08I7ptZVL6/NI3yF+1jaKo8wcUD/WNSC+OEW9BgmAz1Xa3fj /muao24RJr6CAVEwFjpMxCrcJWAuKo0L2wzrO2jdr1bRwzAOcVM= =Dm8F -----END PGP SIGNATURE----- --Apple-Mail=_884E323C-FE30-42F4-B7BA-EC40E1B7EE6D-- From nobody Tue Jul 28 06:16:10 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7CD3A0C13 for ; Tue, 28 Jul 2020 06:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eecrbJ0BenaT for ; Tue, 28 Jul 2020 06:16:04 -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 883C83A0C6F for ; Tue, 28 Jul 2020 06:15:19 -0700 (PDT) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 3C6CE1B00592 for ; Tue, 28 Jul 2020 16:15:17 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1595942117; 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=92ZdcP6MpH2R3k2BoZqKVx4szZs8yJtKJaCPULOfBrM=; b=QjQ2mzpkuF8KZw6DF/yINqHvlE8vmtegeXBQqv2/E83Xp+NXnN0C0xfnRGJ0F/1i7VATSe IN9V85AQW2303J7r8PkphsbcbxkiAizj9MrJEFALXay+LlfWW+ty5fs/WZ5p3tVWZgSfvv qfPjWVgkVgJebOEBJ+J8KR7SAQZcSBFD0Fn0oDEEDwjn8ulBBcJbA1Vrc4iM7p813lVMUt FfUwh/KOF/hpZnkhQPrUPd2A/NxD6Nfil+RecOa9JCUMo32/Xdu/uo3cKJK81k67Bx/wBs LdUW0Z0gavQwDIH/5XsibKEGiG2WXZ2mldxAbqZ+9i/Cy/gcZV80Lf1wMem5FA== Received: by fireball.acr.fi (Postfix, from userid 15204) id CAE5625C0E71; Tue, 28 Jul 2020 16:15:16 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24352.9444.775247.214537@fireball.acr.fi> Date: Tue, 28 Jul 2020 16:15:16 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 15 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1595942117; 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=92ZdcP6MpH2R3k2BoZqKVx4szZs8yJtKJaCPULOfBrM=; b=Nn3ikBu8oWlr9AdDUs1bH3l1Q2veXSiLx00pOqq9VCbgg3qin+BDShLGwnj2w5dAp6WtJQ BPkXEvmTnf82UKoJh1TzUsFEPrrga69nKtDsPLN9/uW7h1NKcdKSDborqYpTaFh9h3+1Fv YFRyaflKPrDmaljjIpOuSFaHiR/06SXFb5YZVUXuQTRy66qc6k/woIfqYtre5wJ+Jka/E8 v8G4bpxFEbVNGc19ouiSXaxxrgfWVCH2OZ1yVd09LLYWyWiRDmX0uPBVi30gTLxEkb4ELB kWpv2AuIkGzWOHkR5tCFFAbsaBMceR7P5Tf+/nk2RVEgncUaZUmOv+r4gnXLXg== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1595942117; a=rsa-sha256; cv=none; b=VI85Rgd9dQC8J60T0aCtfQjmJtw9EgTxHVEsttcVHHZz3z1iZcXJL71TJxpsdn3fDa46k4 xSKJqJWn1SNMQVvjQ+mTUH5BnfdL8wBshyCLFMlYRzAzPD0RyFErA0toyh9dHlXareoBVD Wu3FSbQ1YVrC7SFUDsIzfzXavq2ZaJnRsZF+0pxPY3Ehgd5m/Z3hTP/cGzG/2LWS8gdZqi ivhxNrkLOa4Rki8GZvNyZDrnj2U7Dw0ii113QIUokULC60kbqFXhh62V+lguwNp8/v6Fue nITZgMNjr5c4H5g4Z40IAnPsEajDPqPU+PP/6OgMxhTcpzGDkTpe0XiDcVUAxQ== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: [IPsec] Preliminary minutes from the IETF 108 IPsecME WG Meeting 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, 28 Jul 2020 13:16:08 -0000 Here is preliminary minues from the IETF 108 IPsecME WG meeting. I copied some discussion about the proposed changes to ESP from Jabber to here, as I think it was important to record those even when we did not have time to have comments during the meeting. If you have any comments, please send them to me as soon as possible. ---------------------------------------------------------------------- # IPsecME IETF 108 Time: Tuesday, 28-Jul-2020, at 11:00-12:40 UTC ## Agenda: * 11:00-11:05 - Note Well, technical difficulties and agenda bashing * 11:05-11:10 - Document status (chairs) * 11:10-11:25 - draft-smyslov-ipsecme-rfc8229bis (Valery/Tommy) * 11:25-11:35 - draft-btw-add-ipsecme-ike-00 (Valery) * 11:35-11:45 - draft-smyslov-ipsecme-ikev2-auth-announce (Valery) * 11:45-12:00 - Proposed improvements to ESP (Michael Rossberg) * 12:00-12:15 - IPTFS (Christian Hopps) * 12:15-12:30 - YANG model for IPTFS (Christian Hopps) * 12:30-12:40 - AOB + Open Mic ### Note Well, technical difficulties and agenda bashing *Chairs* (5min) No Edits ### Document status *chairs* (5min) *-implicit-Iv published as RFC8750 *-qr-ikev2 published as RFC8784 *-ipv6-ipv4-codes publication requested ### draft-smyslov-ipsecme-rfc8229bis (TCP encap of IKE/IPsec) *Valery/Tommy* (15min) Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-rfc8229bis-00 Paul Wouters: What are the kernel implications? And does this allow for smaller IPsec/ESP Packets? Valery: Text is a bit short, TCP stream packets will have same class Paul: What Interop testing has been done? Valery: Tested with Apple, Cisco, libreswan Piannissimo Hum for who has read the draft Paul: Good idea to adopt, found issues that would be good to incorporate in draft Yoav: Will take to list if we need an update to 8229 and if this is the right starting point. ### draft-btw-add-ipsecme-ike-00 (IKEv2 config for Encrypted DNS) *Valery* (10min) Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-ikev2-configuration-for-encrypted-dns-00 Paul: What to do outside of VPN tunnel seems out of scope? (regarding Scope bit) Valery: Still an interesting subject Ben (AD): (missed first point Belongs in ADD?) Slide with attribute format, for DoH, need to provide URI template Valery: Presentation also requested in ADD, but didn't have room in agenda. Re: URI, will be covered in DoH clarifications (?) Ben: When DoQ arrives may need additional work Tero: Add configuration attributes, less internal strucutre, more higher level structure Yoav (participant): Missing motivation from draft Moving towards encrypted world, don't want to force people to keep insecure DNS just for legacy IKEv2 server Valery: That is one of the motivations; users won't see this, but it is useful. Tirumaleswar Reddy: URL can be discovered another way Benedict Wong: My understanding is that in some cases we need a hostname to do validation of the DoT server Tirumaleswar: This only supports PKI-based verification, so we can verify based on sent certificate. Yoav: Calling for adoption? Valery: ADD Primary target for adoption, ipsecme is just informational, if there is interest it could persist in this WG, but not yet. Tirumaleswar: Couple more revisions necessary, extension to IKE, want to make sure both working groups are aware of work Ben (AD): If ipsecme was concerned by the work, or on the other hand thinks it makes sense, it's good information for ADD to have ### draft-smyslov-ipsecme-ikev2-auth-announce *Valery* (10min) Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-announcing-supported-authentication-methods-in-ikev2-00 Paul: Good idea, unclear where complexity might be, in the past migration between methods (null -> something else) needed a ppk hack - sending two auth payloads Tero (participant): Could have one part negotiate the algorithm, and the second part to negotiate the algorithm ids for CAs in the certreq Yoav: will take a call for adoption to the list ### Proposed improvements to ESP *Michael Rossberg* (15min) Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-proposed-improvements-to-esp-01 Yoav (?): Discussion happening on list and in jabber. Informational would be wrong, changes packet on wire, so experimental or standards track if anything Summary of questions and comments from the jabber: * Yoav: Some firewalls would be very upset about this packet format, because it looks like every packet is retransmission. * Paul: so flip sender/window id with sequence number * Chopps: andeven put the higher order after lower order so stays exactly the same as before * Scott Fluhrer: In addition, each sending id/window id has its own replay window, does that mean that the receiver needs to track 4 billion antireplay windows? * Scott: Also, it wouldn't be secure with CBC * Paul: It drops all non-AEAD, which we should do anyways * Scott: You also lose the multitarget protection with GCM by not including the 32 bits of key-derived nonce * chopps: The sender id is really a mcast thing, so it reduces to 64k * Scott: Does the receiver need to track a antireplay window for each multicast sender? * Yaov: Yes * Scott: I can't see how that can work on a decryptor that can't dynamically allocate memory * Bob Moskowitz: Would need a change to robust header compression so that smaller seq# for constrained links? * Valery: This proposal lacks enough generality to replace ESP - it considers very small set of ciphers and use cases * Paul: and we might as well throw in a discussion of implicit IV if we are updating ESP to v4 * Yoav: @Valery: doesn't it use all the ciphers that people care about now? Consider that TLS 1.3 has about two ciphers (plus another 1 for IOT). * Valery: In addition, many things it aims for can be achieved using ESP. Even replay protection for multicast (with some limitations). * Steffen Klassert: Get rid of the trailer would be nice from implementation point of view * Valery: @yoav, No, it doesn't work with CBC at all. Moreover, if IV is somehow structured, it won't work too * Yoav: TLS 1.3 doesn't support CBC either. * Valery: I understand, but what if tomorrow a new cipher mode appear that is superior to GCM and will require some special form of IV? The problem is that this design requires IV to be in a particular form. If cipher requires other form, it'll fail Tero: Not in charter, this is a big change. See if it is a good idea first before taking to much time discussing and writing ### IPTFS -- [draft-ietf-ipsecme-iptfs-01](https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-01) *Christian Hopps* (15min) Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-ip-traffic-flow-security-00 Yoav: Hasn't gotten much review, WGLC is one way, but don't know if it is the best way. Requesting transport area early may be a good way too. Tero: Might be hard to get another protocol number. Lou: Getting a protocol number shouldn't be a big deal; many can be deprecated. Ben: Please fill out the official early-allocation form request. Agreed on sending this out for transport area early review. ### YANG model for IPTFS -- [draft-fedyk-ipsecme-yang-iptfs-00](https://tools.ietf.org/html/draft-fedyk-ipsecme-yang-iptfs-00) *Christian Hopps* (15min) Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-yang-model-for-ip-traffic-flow-security-00 Tero: SDN YANG models generally work in two mode, either IKE-less, where it configures IPsec SAs, or in IKE mode where it does not touch IPsec SAs, as IKE configures them, so they wanted to keep the configuration clear which parts they are configuring. Christian: Also operational state, even if not configured via YANG Tero: If we could consolidate on a single YANG model, that would be ideal (such as I2NFS) Yoav: Per chat, would benefit from a YANG Dr. review Lou: Would benefit from another review, per datatracker, latest draft needs another review. ### AOB + Open Mic *all* (10min) Paul: Labeled IPsec still in review. Graveyard draft still in limbo Tero: Take to list; a few of these can go to WGLC, but should check with AD first. Tero: I think we need to have interm meeting about the ESP. We cut the discussion out from here, as it would have taken the rest of the time, but we should have separate interm just for it. -- kivinen@iki.fi From nobody Tue Jul 28 06:29:32 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9D43A0C1C; Tue, 28 Jul 2020 06:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YObjgmxnE9Ed; Tue, 28 Jul 2020 06:29:23 -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 7BA333A0C1B; Tue, 28 Jul 2020 06:29:22 -0700 (PDT) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 4D87E1B00393; Tue, 28 Jul 2020 16:29:20 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1595942960; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=sdyb2jReLnoHCXE42j7tyqRNbd6FepuO9x3SQfBjuxE=; b=Jc7zpefORBWgv5rR05Zt1y6jJpksOM+tjtCm/qjze0e2FXOM4hqC4MrWHbRpHn0gILTa5t uLqJLK25R5SV33kh4X5I0mdgLDnRuPW9Ry0ZVQx67gv/ovPV+HFSyZZr/2NaklEzyRZr+y jQFah/O9RbVyWMfwlzFdaAvzgRBUXyi38Kgsel9MseLd3bDDaI7atslkC+Ku7CPaptbb2r r+ZDQqNPBgw4D0qU0mhjbyrPDvcBCFQ5c8w0evC9dk/iQ56OpEnHsspylimTO4sZEpdNuG LMIhz+iQzGgtn1qXfKjOWlH13ev4UVXjnVkHcPJMZVZ2TCxSHhHk8K8dUxLCGw== Received: by fireball.acr.fi (Postfix, from userid 15204) id 0655125C0E74; Tue, 28 Jul 2020 16:29:20 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24352.10287.977688.473083@fireball.acr.fi> Date: Tue, 28 Jul 2020 16:29:19 +0300 From: Tero Kivinen To: saag@ietf.org CC: ipsec@ietf.org X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 1 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1595942960; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=sdyb2jReLnoHCXE42j7tyqRNbd6FepuO9x3SQfBjuxE=; b=AkBHWXquyV4in+716d570bYryshV9sCfXm+4UqBI8ujNbkRK8AjuRtg9Cqnp3AtLGi4Yz2 6QObOuGWiaJ/sKoibeSwyLjLyBttg54X1bvdah4wPvrIDLDbT8JM25REXSdRmTXY1z3S7d /wZuPjXORM7CUR3lJLPDMP9Sw6kWfytdWmtcjj/F7LRH4OK0OkyhCvbWDlyxruP1ei9w27 iKvjwxvEMUxIGa8hD1kQW1ARTAoT1CHshe6gdEu+DWmQHC5UQwpJECppIpf5IKApZTVLUm 6mDPyUSWs0K3C8cVy6qMEwSyzNk29rpSgTn4nmjPnESqLcZnKS9YqhPDy8vg6A== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1595942960; a=rsa-sha256; cv=none; b=ALfK3j5SU/UVULB6EowIipNDdLa6HT3Cu8BshgSP9Od6t1FVL6uQpgYKLjBv7VYWIWo6B5 XQeP90cjZ3aUIZKLhNghY8sKrDjYeRB8Fw+N4RG9LAkNx5LBSZxvpz1lJRSwNjwZxObh0x xAiPdFsndN+qPih6Ni8AhSFwFbIHDaTc67oK0ng5qkPSWvd8I0O/e2Y7OGv005jb8OaoSE GU2jsG92spnr5yKGaoLRzWgi8uHGf4Je5K4Rr0Ksh2PcIjYsS9o/osOBzNysAnbWR/Mn6k wsFc+do1H2yJFh+tFeLwxvrfAY+5y0i+HqAO39BjdRs2Z1/v1IFEkDjGk50Usg== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: [IPsec] IPsec WG Report for SAAG 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, 28 Jul 2020 13:29:26 -0000 This has also been stored in the datatracker as status update for the IPsecME WG (https://datatracker.ietf.org/group/ipsecme/about/status/). ---------------------------------------------------------------------- Implicit IV was published as RFC8750, and Mixing Preshared Keys in the IKEv2 for Post-quantum Security was published as RFC8784. Publication requested has been issued for IPv6 and IPv4 status codes. For the existing work items, the IKEv2 intermediate is ready for WGLC, and Multiple KE should also be ready for WGLC. The G-IKEv2 draft had major rewrite to make it more inline with IKEv2. The IP traffic flow security draft is getting ready for early transport area review, and it is starting the process of getting protocol number to be allocated for it. Labeled IPsec is mostly waiting to get some implementation experience, there are implementations in the process of being developed. IKE1 IPsec graveyard draft is not yet adopted, and needs for authors to agree with ADs what to do with it, i.e., whether it will be WG item, or AD sponsored document. Clarifications and Implementation guidelines for using TCP encapsulation in IKEv2 has been changed to be RFC8229bis instead of separate clarification document, and is now getting ready for WG adoption. There is new draft for the Announcing Supported Authentication Methods in IKEv2 charter item, which might be adopted as WG item after people have had time to review it. -- kivinen@iki.fi From nobody Tue Jul 28 13:22:27 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45FA63A0C34 for ; Tue, 28 Jul 2020 13:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzNA_jAN0Qq0 for ; Tue, 28 Jul 2020 13:22:15 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 E61833A0B45 for ; Tue, 28 Jul 2020 13:22:14 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id a14so19521862wra.5 for ; Tue, 28 Jul 2020 13:22:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=fn1sfWBdlHOczR0IIpvs7mLCxVp6k+AV5MAJ70NYWEI=; b=a3JjM4ftzh53+/hxPf6eexTq8menmEb/dEwRFdTkm+b3yH7VHr1RtuYyvZPM3Lq3wM Gk8AydmmVATN9URsKcKpgB9seLlfGlhfRx4vdY9i1VFBpVFWuyxeFjkJcJS6/bE3n+d8 Pg5ftMzIKhO5of0PLq2xyLOXGWxj3QUo+7XYMrr1F8nQVtxmhvHZaFbX8vedX9auFCbr lTTu3e3whz4FcpTN2dPyK3T8rHZM/mU4xDVQGTeJLlS80YpqGuiJ4PsVx2PUkXGl0h6F u3nH0lmISBM3YmBXbISgXB7O2U1qv9dIjYLsoSSFaSlziXWKDoz6Or/8u+b23AWTRz9O JPkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=fn1sfWBdlHOczR0IIpvs7mLCxVp6k+AV5MAJ70NYWEI=; b=HkkygMoLmBxrbT1bcXmdHpNKWbEvfyEppS8P1fldtQOKCU/zUDQuWPHs/7aKZAL1kH gT5MYrj8rzq401IscvnFK5rOQzIL7ZDSz2MaqcPlxxE2vE7EvivMqfbMXq8r9CRmrBUR 5LuCJfQ3qDZey0X2woT3s7oWccybA9sZx+XoBi/7SFWAv0JaGxATP+q2knt5D0i4vqMY oRlH7nTJxFG8BSvLF5xHZM8lklwI4+pTFhbcX3SfkT5YbX14dQ08LB+N5T5LyKsznIhk c2IbZssE3LK9sVLoGx1MYCsig4D3EZo6mtHORYWIPXU/voF9DPeVZ4uic0bu0RkoPm9d VZTw== X-Gm-Message-State: AOAM533jqvZDoaE5voEJXsQrFJRiGjbD6pOJR8nW+8coMPFGTTt1aEQ1 vLPHgzePirfQ7iL34GjEzmk= X-Google-Smtp-Source: ABdhPJxgECgFiydo1GA4QPpUY9tvWxjZFb2pg15zd6g2ePRBqobMHqwJJPGYSkCHj39ATq18HurDhQ== X-Received: by 2002:a5d:4407:: with SMTP id z7mr25923454wrq.404.1595967733454; Tue, 28 Jul 2020 13:22:13 -0700 (PDT) Received: from [192.168.1.17] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id o2sm19382976wrj.21.2020.07.28.13.22.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jul 2020 13:22:12 -0700 (PDT) From: Yoav Nir Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_55265EF5-65A7-4D4A-846F-0C9F7DCECC07" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Tue, 28 Jul 2020 23:22:11 +0300 In-Reply-To: <24352.9444.775247.214537@fireball.acr.fi> Cc: ipsec@ietf.org To: Tero Kivinen References: <24352.9444.775247.214537@fireball.acr.fi> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [IPsec] Preliminary minutes from the IETF 108 IPsecME WG Meeting 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, 28 Jul 2020 20:22:25 -0000 --Apple-Mail=_55265EF5-65A7-4D4A-846F-0C9F7DCECC07 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi. I uploaded a PDF version to the meeting materials. Also added a list of = action items for the chairs. Comments are welcome on that part as well. https://www.ietf.org/proceedings/108/minutes/minutes-108-ipsecme-00 = Yoav > On 28 Jul 2020, at 16:15, Tero Kivinen wrote: >=20 > Here is preliminary minues from the IETF 108 IPsecME WG meeting. I > copied some discussion about the proposed changes to ESP from Jabber > to here, as I think it was important to record those even when we did > not have time to have comments during the meeting.=20 >=20 > If you have any comments, please send them to me as soon as possible.=20= > ---------------------------------------------------------------------- > # IPsecME IETF 108 >=20 > Time: Tuesday, 28-Jul-2020, at 11:00-12:40 UTC >=20 > ## Agenda: > * 11:00-11:05 - Note Well, technical difficulties and agenda bashing > * 11:05-11:10 - Document status (chairs) > * 11:10-11:25 - draft-smyslov-ipsecme-rfc8229bis (Valery/Tommy) > * 11:25-11:35 - draft-btw-add-ipsecme-ike-00 (Valery) > * 11:35-11:45 - draft-smyslov-ipsecme-ikev2-auth-announce (Valery) > * 11:45-12:00 - Proposed improvements to ESP (Michael Rossberg) > * 12:00-12:15 - IPTFS (Christian Hopps) > * 12:15-12:30 - YANG model for IPTFS (Christian Hopps) > * 12:30-12:40 - AOB + Open Mic >=20 > ### Note Well, technical difficulties and agenda bashing > *Chairs* (5min) >=20 > No Edits >=20 > ### Document status > *chairs* (5min) >=20 > *-implicit-Iv published as RFC8750 > *-qr-ikev2 published as RFC8784 >=20 > *-ipv6-ipv4-codes publication requested >=20 > ### draft-smyslov-ipsecme-rfc8229bis (TCP encap of IKE/IPsec) > *Valery/Tommy* (15min) >=20 > Slides link: = https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-rfc8229bis-= 00 >=20 > Paul Wouters: What are the kernel implications? And does this allow = for smaller IPsec/ESP Packets? > Valery: Text is a bit short, TCP stream packets will have same class > Paul: What Interop testing has been done? > Valery: Tested with Apple, Cisco, libreswan >=20 > Piannissimo Hum for who has read the draft >=20 > Paul: Good idea to adopt, found issues that would be good to = incorporate in draft >=20 > Yoav: Will take to list if we need an update to 8229 and if this is = the right starting point. >=20 > ### draft-btw-add-ipsecme-ike-00 (IKEv2 config for Encrypted DNS) > *Valery* (10min) >=20 > Slides link: = https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-ikev2-confi= guration-for-encrypted-dns-00 >=20 > Paul: What to do outside of VPN tunnel seems out of scope? (regarding = Scope bit) >=20 > Valery: Still an interesting subject >=20 > Ben (AD): (missed first point Belongs in ADD?) Slide with attribute = format, for DoH, need to provide URI template >=20 > Valery: Presentation also requested in ADD, but didn't have room in = agenda. Re: URI, will be covered in DoH clarifications (?) >=20 > Ben: When DoQ arrives may need additional work >=20 > Tero: Add configuration attributes, less internal strucutre, more = higher level structure >=20 > Yoav (participant): Missing motivation from draft Moving towards = encrypted world, don't want to force people to keep insecure DNS just = for legacy IKEv2 server=20 >=20 > Valery: That is one of the motivations; users won't see this, but it = is useful. >=20 > Tirumaleswar Reddy: URL can be discovered another way >=20 > Benedict Wong: My understanding is that in some cases we need a = hostname to do validation of the DoT server >=20 > Tirumaleswar: This only supports PKI-based verification, so we can = verify based on sent certificate. >=20 > Yoav: Calling for adoption? >=20 > Valery: ADD Primary target for adoption, ipsecme is just = informational, if there is interest it could persist in this WG, but not = yet. >=20 > Tirumaleswar: Couple more revisions necessary, extension to IKE, want = to make sure both working groups are aware of work >=20 > Ben (AD): If ipsecme was concerned by the work, or on the other hand = thinks it makes sense, it's good information for ADD to have >=20 > ### draft-smyslov-ipsecme-ikev2-auth-announce > *Valery* (10min) >=20 > Slides link: = https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-announcing-= supported-authentication-methods-in-ikev2-00 >=20 > Paul: Good idea, unclear where complexity might be, in the past = migration between methods (null -> something else) needed a ppk hack - = sending two auth payloads >=20 > Tero (participant): Could have one part negotiate the algorithm, and = the second part to negotiate the algorithm ids for CAs in the certreq >=20 > Yoav: will take a call for adoption to the list >=20 > ### Proposed improvements to ESP > *Michael Rossberg* (15min) >=20 > Slides link: = https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-proposed-im= provements-to-esp-01 >=20 > Yoav (?): Discussion happening on list and in jabber. Informational = would be wrong, changes packet on wire, so experimental or standards = track if anything >=20 > Summary of questions and comments from the jabber: >=20 > * Yoav: Some firewalls would be very upset about this packet format, = because it looks like every packet is retransmission. > * Paul: so flip sender/window id with sequence number > * Chopps: andeven put the higher order after lower order so stays = exactly the same as before > * Scott Fluhrer: In addition, each sending id/window id has its own = replay window, does that mean that the receiver needs to track 4 billion = antireplay windows? > * Scott: Also, it wouldn't be secure with CBC > * Paul: It drops all non-AEAD, which we should do anyways > * Scott: You also lose the multitarget protection with GCM by not = including the 32 bits of key-derived nonce > * chopps: The sender id is really a mcast thing, so it reduces to 64k > * Scott: Does the receiver need to track a antireplay window for each = multicast sender? > * Yaov: Yes > * Scott: I can't see how that can work on a decryptor that can't = dynamically allocate memory > * Bob Moskowitz: Would need a change to robust header compression so = that smaller seq# for constrained links? > * Valery: This proposal lacks enough generality to replace ESP - it = considers very small set of ciphers and use cases > * Paul: and we might as well throw in a discussion of implicit IV if = we are updating ESP to v4 > * Yoav: @Valery: doesn't it use all the ciphers that people care about = now? Consider that TLS 1.3 has about two ciphers (plus another 1 for = IOT). > * Valery: In addition, many things it aims for can be achieved using = ESP. Even replay protection for multicast (with some limitations). > * Steffen Klassert: Get rid of the trailer would be nice from = implementation point of view > * Valery: @yoav, No, it doesn't work with CBC at all. Moreover, if IV = is somehow structured, it won't work too > * Yoav: TLS 1.3 doesn't support CBC either. > * Valery: I understand, but what if tomorrow a new cipher mode appear = that is superior to GCM and will require some special form of IV? The = problem is that this design requires IV to be in a particular form. If = cipher requires other form, it'll fail >=20 > Tero: Not in charter, this is a big change. See if it is a good idea = first before taking to much time discussing and writing >=20 > ### IPTFS -- = [draft-ietf-ipsecme-iptfs-01](https://tools.ietf.org/html/draft-ietf-ipsec= me-iptfs-01) > *Christian Hopps* (15min) >=20 > Slides link: = https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-ip-traffic-= flow-security-00 >=20 > Yoav: Hasn't gotten much review, WGLC is one way, but don't know if it = is the best way. Requesting transport area early may be a good way too. >=20 > Tero: Might be hard to get another protocol number. >=20 > Lou: Getting a protocol number shouldn't be a big deal; many can be = deprecated. >=20 > Ben: Please fill out the official early-allocation form request. >=20 > Agreed on sending this out for transport area early review. >=20 > ### YANG model for IPTFS -- = [draft-fedyk-ipsecme-yang-iptfs-00](https://tools.ietf.org/html/draft-fedy= k-ipsecme-yang-iptfs-00) > *Christian Hopps* (15min) >=20 > Slides link: = https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-yang-model-= for-ip-traffic-flow-security-00 >=20 > Tero: SDN YANG models generally work in two mode, either IKE-less, = where it configures IPsec SAs, or in IKE mode where it does not touch = IPsec SAs, as IKE configures them, so they wanted to keep the = configuration clear which parts they are configuring. >=20 > Christian: Also operational state, even if not configured via YANG >=20 > Tero: If we could consolidate on a single YANG model, that would be = ideal (such as I2NFS) >=20 > Yoav: Per chat, would benefit from a YANG Dr. review >=20 > Lou: Would benefit from another review, per datatracker, latest draft = needs another review. >=20 > ### AOB + Open Mic > *all* (10min) >=20 > Paul: Labeled IPsec still in review. Graveyard draft still in limbo >=20 > Tero: Take to list; a few of these can go to WGLC, but should check = with AD first. >=20 > Tero: I think we need to have interm meeting about the ESP. We cut the = discussion out from here, as it would have taken the rest of the time, = but we should have separate interm just for it. > --=20 > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail=_55265EF5-65A7-4D4A-846F-0C9F7DCECC07 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi.

I = uploaded a PDF version to the meeting materials. Also added a list of = action items for the chairs.  Comments are welcome on that part as = well.

https://www.ietf.org/proceedings/108/minutes/minutes-108-ipsecm= e-00

Yoav

On 28 Jul 2020, at 16:15, Tero Kivinen <kivinen@iki.fi> = wrote:

Here is preliminary minues from the IETF 108 IPsecME WG = meeting. I
copied some discussion about the proposed = changes to ESP from Jabber
to here, as I think it was = important to record those even when we did
not have time = to have comments during the meeting.

If = you have any comments, please send them to me as soon as possible.
---------------------------------------------------------------= -------
# IPsecME IETF 108

Time: Tuesday, 28-Jul-2020, at 11:00-12:40 UTC

## Agenda:
* 11:00-11:05 - Note = Well, technical difficulties and agenda bashing
* = 11:05-11:10 - Document status (chairs)
* 11:10-11:25 - = draft-smyslov-ipsecme-rfc8229bis (Valery/Tommy)
* = 11:25-11:35 - draft-btw-add-ipsecme-ike-00 (Valery)
* = 11:35-11:45 - draft-smyslov-ipsecme-ikev2-auth-announce (Valery)
* 11:45-12:00 - Proposed improvements to ESP (Michael = Rossberg)
* 12:00-12:15 - IPTFS (Christian Hopps)
* 12:15-12:30 - YANG model for IPTFS (Christian Hopps)
* 12:30-12:40 - AOB + Open Mic

###= Note Well, technical difficulties and agenda bashing
*Chairs* (5min)

No Edits

### Document status
*chairs* = (5min)

*-implicit-Iv published as = RFC8750
*-qr-ikev2 published as RFC8784

*-ipv6-ipv4-codes publication requested

### draft-smyslov-ipsecme-rfc8229bis (TCP encap of = IKE/IPsec)
*Valery/Tommy* (15min)

Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-= rfc8229bis-00

Paul Wouters: What are = the kernel implications? And does this allow for smaller IPsec/ESP = Packets?
Valery: Text is a bit short, TCP stream packets = will have same class
Paul: What Interop testing has been = done?
Valery: Tested with Apple, Cisco, libreswan

Piannissimo Hum for who has read the draft

Paul: Good idea to adopt, found issues that = would be good to incorporate in draft

Yoav: = Will take to list if we need an update to 8229 and if this is the right = starting point.

### = draft-btw-add-ipsecme-ike-00 (IKEv2 config for Encrypted DNS)
*Valery* (10min)

Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-= ikev2-configuration-for-encrypted-dns-00

Paul: What to do outside of VPN tunnel seems out of scope? = (regarding Scope bit)

Valery: Still an = interesting subject

Ben (AD): (missed first = point Belongs in ADD?) Slide with attribute format, for DoH, need to = provide URI template

Valery: Presentation = also requested in ADD, but didn't have room in agenda.  Re: URI, = will be covered in DoH clarifications (?)

Ben: When DoQ arrives may need additional work

Tero: Add configuration attributes, less = internal strucutre, more higher level structure

Yoav (participant): Missing motivation from draft =  Moving towards encrypted world, don't want to force people to keep = insecure DNS just for legacy IKEv2 server

Valery: That is one of the motivations; users won't see this, = but it is useful.

Tirumaleswar Reddy: URL = can be discovered another way

Benedict = Wong: My understanding is that in some cases we need a hostname to do = validation of the DoT server

Tirumaleswar: = This only supports PKI-based verification, so we can verify based on = sent certificate.

Yoav: Calling for = adoption?

Valery: ADD Primary target for = adoption, ipsecme is just informational, if there is interest it could = persist in this WG, but not yet.

Tirumaleswar: Couple more revisions necessary, extension to = IKE, want to make sure both working groups are aware of work

Ben (AD): If ipsecme was concerned by the = work, or on the other hand thinks it makes sense, it's good information = for ADD to have

### = draft-smyslov-ipsecme-ikev2-auth-announce
*Valery* = (10min)

Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-= announcing-supported-authentication-methods-in-ikev2-00

Paul: Good idea, unclear where complexity = might be, in the past migration between methods (null -> something = else) needed a ppk hack - sending two auth payloads

Tero (participant): Could have one part negotiate the = algorithm, and the second part to negotiate the algorithm ids for CAs in = the certreq

Yoav: will take a call for = adoption to the list

### Proposed = improvements to ESP
*Michael Rossberg* (15min)

Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-= proposed-improvements-to-esp-01

Yoav = (?): Discussion happening on list and in jabber.  Informational = would be wrong, changes packet on wire, so experimental or standards = track if anything

Summary of questions and = comments from the jabber:

* Yoav: Some = firewalls would be very upset about this packet format, because it looks = like every packet is retransmission.
* Paul: so flip = sender/window id with sequence number
* Chopps: andeven = put the higher order after lower order so stays exactly the same as = before
* Scott Fluhrer: In addition, each sending = id/window id has its own replay window, does that mean that the receiver = needs to track 4 billion antireplay windows?
* Scott: = Also, it wouldn't be secure with CBC
* Paul: It drops all = non-AEAD, which we should do anyways
* Scott: You also = lose the multitarget protection with GCM by not including the 32 bits of = key-derived nonce
* chopps: The sender id is really a = mcast thing, so it reduces to 64k
* Scott: Does the = receiver need to track a antireplay window for each multicast sender?
* Yaov: Yes
* Scott: I can't see how that can = work on a decryptor that can't dynamically allocate memory
*= Bob Moskowitz: Would need a change to robust header compression so that = smaller seq# for constrained links?
* Valery: This = proposal lacks enough generality to replace ESP - it considers very = small set of ciphers and use cases
* Paul: and we might as = well throw in a discussion of implicit IV if we are updating ESP to = v4
* Yoav: @Valery: doesn't it use all the ciphers that = people care about now? Consider that TLS 1.3 has about two ciphers (plus = another 1 for IOT).
* Valery: In addition, many things it = aims for can be achieved using ESP. Even replay protection for multicast = (with some limitations).
* Steffen Klassert: Get rid of = the trailer would be nice from implementation point of view
* Valery: @yoav, No, it doesn't work with CBC at all. = Moreover, if IV is somehow structured, it won't work too
* = Yoav: TLS 1.3 doesn't support CBC either.
* Valery: I = understand, but what if tomorrow a new cipher mode appear that is = superior to GCM and will require some special form of IV? The problem is = that this design requires IV to be in a particular form. If cipher = requires other form, it'll fail

Tero: Not = in charter, this is a big change.  See if it is a good idea first = before taking to much time discussing and writing

### IPTFS -- [draft-ietf-ipsecme-iptfs-01](https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-01)*Christian Hopps* (15min)

Slides = link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-= ip-traffic-flow-security-00

Yoav: = Hasn't gotten much review, WGLC is one way, but don't know if it is the = best way. Requesting transport area early may be a good way too.

Tero: Might be hard to get another protocol = number.

Lou: Getting a protocol number = shouldn't be a big deal; many can be deprecated.

Ben: Please fill out the official early-allocation form = request.

Agreed on sending this out for = transport area early review.

### YANG model = for IPTFS -- [draft-fedyk-ipsecme-yang-iptfs-00](https://tools.ietf.org/html/draft-fedyk-ipsecme-yang-iptfs-00)
*Christian Hopps* (15min)

Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-= yang-model-for-ip-traffic-flow-security-00

Tero: SDN YANG models generally work in two mode, either = IKE-less, where it configures IPsec SAs, or in IKE mode where it does = not touch IPsec SAs, as IKE configures them, so they wanted to keep the = configuration clear which parts they are configuring.

Christian: Also operational state, even if not configured via = YANG

Tero: If we could consolidate on a = single YANG model, that would be ideal (such as I2NFS)

Yoav: Per chat, would benefit from a YANG Dr. review

Lou: Would benefit from another review, per = datatracker, latest draft needs another review.

### AOB + Open Mic
*all* (10min)

Paul: Labeled IPsec still in review. Graveyard = draft still in limbo

Tero: Take to list; a = few of these can go to WGLC, but should check with AD first.

Tero: I think we need to have interm meeting = about the ESP. We cut the discussion out from here, as it would have = taken the rest of the time, but we should have separate interm just for = it.
--
kivinen@iki.fi

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

= --Apple-Mail=_55265EF5-65A7-4D4A-846F-0C9F7DCECC07-- From nobody Tue Jul 28 14:24:45 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436E43A088A for ; Tue, 28 Jul 2020 14:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=ZiswOX7Z; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=VZNkRhgz 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 ImR3T2LZxA4F for ; Tue, 28 Jul 2020 14:24:42 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50F1E3A0883 for ; Tue, 28 Jul 2020 14:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10023; q=dns/txt; s=iport; t=1595971482; x=1597181082; h=from:to:subject:date:message-id:mime-version; bh=KHpGe2UKySs1cm/9BkCpMcqzD8bds5fMBTmJ4eEzZU8=; b=ZiswOX7ZwQg0wiNS5fnSZa+BfEXdFNfHsDtVlM70N8e6s66L1oFFVgFv wp/klLKrtICI+MN3hVCLlI+0uBovjTRIRWmxRmhbw/Lg2aHBP2neJVgJV fItM9VBNhMbj97JAc3DKDl1I7J7jb1UXE4zQPx1OHwtKUOJ7n3A8Ivwky M=; IronPort-PHdr: =?us-ascii?q?9a23=3A/k04XREqXYG6nrQ0f+sdJp1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401QWbXIjH5bRDkeWF+6zjWGlV55GHvThCdZFXTB?= =?us-ascii?q?YKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGGcviaRvVuHLhpTIXEw?= =?us-ascii?q?/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxneas=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CJCACnliBf/4sNJK1ggQmBSoEjL1E?= =?us-ascii?q?Hb1gvLAqHcAORFZA2hGyCUwNVCwEBAQwBAS0CBAEBhEwCgiACJDcGDgIDAQE?= =?us-ascii?q?LAQEFAQEBAgEGBG2FXAyGChsTAQEsDBEBgQAmAQQbGoMFgX5NAy4BpS4CgTm?= =?us-ascii?q?IYXSBNIMBAQEFhSwYgg4JgTiCbYlyHhqBQT+BVIdKg0eCLY9KiXabMoEFCoJ?= =?us-ascii?q?fmhGfabExAgQCBAUCDgEBBYFpJIFXcBU7gmlQFwINjioXg06KVnQ3AgYIAQE?= =?us-ascii?q?DCXyNOC2BBgGBEAEB?= X-IronPort-AV: E=Sophos;i="5.75,407,1589241600"; d="scan'208,217";a="787608290" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Jul 2020 21:24:40 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 06SLOexs012787 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 28 Jul 2020 21:24:40 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 28 Jul 2020 16:24:40 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 28 Jul 2020 17:24:39 -0400 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 28 Jul 2020 16:24:38 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R33DeSPWWB8xFsHRdSpxw1ZbuwqgPljeDGd8OrVmNT4mYup0o7xZYMYovCbvOEL3VlCQbj3xli65lk9EiRhnZjKaECRYy2+ZwDAB6kwDmtvSMRn9I0xxbXy3cLNuikxnoKimjZyL/1FJOo2yFNmsOOeagIrDzouA4VCnZELv+gAvVbcV564dhrywEnVK4BHAYVpfhwj93+Tg1V9v3RHAWCUyM8DqtqFeJnboJsbhWFHBBy5YsBU75NAfecVinTBYrOonH2Qrcj0sn9HYR/MRaN0ULSqLGfeT/8h6JFxiKkdKYZSZcfKi7eMJhzYd3qLnpq8SWcBaqMA+9lOOgr868g== 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=XkhYkEh0spEVVsP6BmXx5CyHf1fleuL2E4QOGIYN0HQ=; b=jf5A5vhr2jkIeBWPqc40W6Bq075szhKuNEy6DcJNrRh4dxidSz6H0Y+39V3m20XiEclgtTaQ1D9tHa5KsLDP78ABuIS3gkQq2m08hkJ34/THre0RIwte7jRDFX6tD33VaepL4sIMjwHYfZLJCOA7Arj50Wp+kMQgXms75ysztMVPMLTCA3F951I04I7rUHPKjWePSXiFLRAGrTN1hWF+iClllY8fQWQJdyz1NuOmizm6abhAypwVi08z1BzdosG77RJC1Vv3/UY2Te25nu86aCQvDLsWWvjgDm2ebsJyWPXWz9E9SyhfecOhoZ5dtFXXo2VegyEpUC8S0GbSUrp+Fw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XkhYkEh0spEVVsP6BmXx5CyHf1fleuL2E4QOGIYN0HQ=; b=VZNkRhgzg4bkxh7oDgFCaazrsHLEVDB5sCkAgJVBezHEygRlmVVGxBapjk6sj1cxBjbGRuVffQVWf1S9CvoZV68uTueH1tl44Bf0P5oaFuIXvWblxgxycwM3kGDBd6XeiGrW5VHFU2qdykeFQOmPddF/Pe1HKAjU0fX8Z0oo4ZQ= Received: from BN7PR11MB2641.namprd11.prod.outlook.com (2603:10b6:406:b1::25) by BN6PR11MB0018.namprd11.prod.outlook.com (2603:10b6:405:68::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.27; Tue, 28 Jul 2020 21:24:37 +0000 Received: from BN7PR11MB2641.namprd11.prod.outlook.com ([fe80::5018:edeb:b77d:4d65]) by BN7PR11MB2641.namprd11.prod.outlook.com ([fe80::5018:edeb:b77d:4d65%3]) with mapi id 15.20.3216.034; Tue, 28 Jul 2020 21:24:37 +0000 From: "Scott Fluhrer (sfluhrer)" To: "'ipsecme mailing list'" Thread-Topic: My comments on "Proposed improvements to ESP" Thread-Index: AdZlIJsCF2D3TEvUStiYcQQYQ4ZDsA== Date: Tue, 28 Jul 2020 21:24:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4bf6e684-58ab-4519-65e1-08d8333ca1c8 x-ms-traffictypediagnostic: BN6PR11MB0018: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ege6mW1+OuIEApOq3pCMHHtOLr23V8EiURHgFGtptAViU13TvWkPsF5/NOV0dRUXtOANZmFPLEYnt7Menh2UZxQYEbdNyG8YK48VJGkizi9P/a9JP0aH0dwOg+U+8k4wXCXf6V4obUDnbSW4JU3Xyd5Fyf7L5Gebft0tOiTtaKc8jM5VmfTkJ3peA/qPBytekGh9kxLOpV7RTctBbcyKjHzVlr4nvujncDO0WdM08MSwBiQITIQ5ui6dPVEVptxOrAQJSvss9ZZHIEaNLqsYlsVZAwS88zQACj0atx9Byg3ncJaMAG5ZZAa/HfoWj55VeG+v+leueCC2pF+kWtbaNA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2641.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(39860400002)(136003)(376002)(396003)(346002)(52536014)(33656002)(83380400001)(71200400001)(316002)(8676002)(6506007)(8936002)(86362001)(66946007)(66556008)(9686003)(478600001)(66476007)(2906002)(7696005)(76116006)(55016002)(5660300002)(186003)(26005)(64756008)(6916009)(66446008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: S1/RV2zJfKnl9tsy46d/4+YpNtm0dBtklXF9PAR4lUWmB1d6bb7/y/cyZFqKXEOtl3bTWLxxSPWXYFmv4SI8o8n81yT0LCcMgApv+rlzr1qfpt6whL57jtfz9jZtSxA14qj7LVz/NGGZvmksVivvKqitHTjw+Vj5wjnLZ1j4We1YhIET1isCX6/T2L5kerCFBi947l09IegII4TSPlAu8O9DnoaEP0Fk7UgGCuhMk0O83dNoDA+VtqsWmFmVFQlaX1O8/Lq0Yy9qwmklNzj6Ka6YpU0JqE5Ml28UGuAumuVbeQGQLObum2d/u5P0OHPO/bYR8WcVBboWxu2RekCBAoVmfXY5ENSAvph+z6nk0m/wGvgO47Ewpoj3uoy+a85vn2YpSdSX/KJiNOZ3I5J6MCUYRCTXHKID/Emw9MLxe/kVvNM0ix3zXylUfgdTAFSdSb8A3reNoeRZOopsg8/IaitUFZxrbpgMo0YipQGJQjI= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN7PR11MB2641FDD2CCC6311DB449B0BCC1730BN7PR11MB2641namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN7PR11MB2641.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4bf6e684-58ab-4519-65e1-08d8333ca1c8 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2020 21:24:37.6745 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 3J/+gYD/G2Sgx1IbehGr0zjHuN3rjrsq6amxPttfj8Dtis+Aqemjscm7DpDW6oM0rF1OVXF13YxwCa7/XxSYEA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB0018 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: alln-core-6.cisco.com Archived-At: Subject: [IPsec] My comments on "Proposed improvements to ESP" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 21:24:44 -0000 --_000_BN7PR11MB2641FDD2CCC6311DB449B0BCC1730BN7PR11MB2641namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I glanced the proposal, and I have doubts as to how well it works, and in p= articular, how well it would work in parallelized decryption. As I underst= and it, the antireplay window the decryptor checks against is specified in = the 'Sender ID/Window ID' field. If the decryptor can handle only one pack= et for a specific antireplay window, then the level of parallelism that the= decryptor can use is entirely up to the encryptor, which might not take th= e decryptor's needs into consideration. For example, if the encryptor deci= des to send every packet with the same Sender ID/Window ID, then the decryp= tor would be forced to use a single thread, which eliminates most of the ad= vantage this proposal claimed to offer. So, does this proposal include any way for the decryptor to suggest (either= at SA negotiation time or dynamically) the behavior the encryptor is suppo= sed to follow? And, if the decryptor can handle a single antireplay window with multiple t= hreads, then most of the parallelizability benefits aren't there (and paral= lelizing in the encrypt direction is fairly straight-forward; the only non-= parallelizable step is assigning the sequence number to each packet, and th= at's comparatively straight-forward). In addition, during the WG meeting, I groused in the chat about requiring t= he receiver to track a large (and not tightly bounded) number of independen= t sequence windows; I believe that is an issue as well. On the IPsec datap= lanes I've worked on, we tried to keep the data structures simple (and we c= ould not dynamically allocate memory if we saw a sender id/window id that w= e hadn't seen before). Now, it has since occurred to me that the data plan= e could have a number of antireplay windows, and if it saw a sender id/wind= ow id that it hadn't seen before, then (after validating the packet), it co= uld send a message to the control plane (which would allocate/refresh the a= ntireplay window, and possible retire a not-recently-used one). However, t= hat strikes me as adding significant complexity. I believe that this was asked on the mailing list already, but I will repea= t it: what advantage does this approach have over the 'having independent S= As with separate SPIs' approach? As for the idea of moving the integrity check value before the encapsulated= packet, well, that idea might help on your platform; however it strikes me= that the advantage would likely be fairly platform dependent. However, if= you are getting rid of the trailer, how would this idea extend to transpor= t mode? Where would you place the NH field (this is a question, not a crit= icism; moving the NH field up front is likely to be a benefit). --_000_BN7PR11MB2641FDD2CCC6311DB449B0BCC1730BN7PR11MB2641namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I glanced the proposal, and I have doubts as to how = well it works, and in particular, how well it would work in parallelized de= cryption.  As I understand it, the antireplay window the decryptor che= cks against is specified in the ‘Sender ID/Window ID’ field.  If the decryptor can handle only one pack= et for a specific antireplay window, then the level of parallelism that the= decryptor can use is entirely up to the encryptor, which might not take th= e decryptor’s needs into consideration.  For example, if the encryptor decides to send every packet with the same Sende= r ID/Window ID, then the decryptor would be forced to use a single thread, = which eliminates most of the advantage this proposal claimed to offer.=

 

So, does this proposal include any way for the decry= ptor to suggest (either at SA negotiation time or dynamically) the behavior= the encryptor is supposed to follow?

 

And, if the decryptor can handle a single antireplay= window with multiple threads, then most of the parallelizability benefits = aren’t there (and parallelizing in the encrypt direction is fairly st= raight-forward; the only non-parallelizable step is assigning the sequence number to each packet, and that’s com= paratively straight-forward).

 

In addition, during the WG meeting, I groused in the= chat about requiring the receiver to track a large (and not tightly bounde= d) number of independent sequence windows; I believe that is an issue as we= ll.  On the IPsec dataplanes I’ve worked on, we tried to keep the data structures simple (and we could not d= ynamically allocate memory if we saw a sender id/window id that we hadnR= 17;t seen before).  Now, it has since occurred to me that the data pla= ne could have a number of antireplay windows, and if it saw a sender id/window id that it hadn’t seen before, then= (after validating the packet), it could send a message to the control plan= e (which would allocate/refresh the antireplay window, and possible retire = a not-recently-used one).  However, that strikes me as adding significant complexity.

 

I believe that this was asked on the mailing list al= ready, but I will repeat it: what advantage does this approach have over th= e ‘having independent SAs with separate SPIs’ approach?

 

As for the idea of moving the integrity check value = before the encapsulated packet, well, that idea might help on your platform= ; however it strikes me that the advantage would likely be fairly platform = dependent.  However, if you are getting rid of the trailer, how would this idea extend to transport mode?  Wh= ere would you place the NH field (this is a question, not a criticism; movi= ng the NH field up front is likely to be a benefit).

 

--_000_BN7PR11MB2641FDD2CCC6311DB449B0BCC1730BN7PR11MB2641namp_-- From nobody Tue Jul 28 22:38:25 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B9D3A0FB7 for ; Tue, 28 Jul 2020 22:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 tP1pvJlcARhk for ; Tue, 28 Jul 2020 22:38:21 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC5D63A0FB6 for ; Tue, 28 Jul 2020 22:38:20 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 4BGj4q1V3BzBtrG; Wed, 29 Jul 2020 07:38:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1596001099; bh=Bbh7/pX6VuX7EuWGm039BqekA0quHFXW6Khx0ImL4u4=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=KQWlY6V6xvPTFrCHXJuSOzRbDzW46HgU3o/iVL4lBY06gl/QwEGB4IQp5t1Z+ejxy 1puW7gFoiWD5nqAYwytlzNO0w3F1cMOu4KDfhCg4pW7Rrl49pbHFpNHnUnbZi0x5T5 rUuVOaOgp/e1bR94Z7Usb4tT03ZotibsRsEpL2FHcY+b3GmVr57nEDLu91Ajz4JSZI bFrzDHQfLkoUS9G2Hp9PE81wK4LMQfVaAHpFTbG9KLrkgm+sR6hSkgEBYVJ/BiJ7lT TExbrB0c7oJgpy6D3g5yAk6c1lC/56wJPBkJhuJxQNHd738MT1FNniuSq4po5hsaeQ AICAujYz0rpUQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.32]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 4BGj4q0K4Sz3wbM; Wed, 29 Jul 2020 07:38:19 +0200 (CEST) From: To: Yoav Nir , Tero Kivinen , "Benjamin Kaduk (kaduk@mit.edu)" CC: "ipsec@ietf.org" Thread-Topic: [IPsec] Preliminary minutes from the IETF 108 IPsecME WG Meeting Thread-Index: AQHWZOFMXSqnWuk2FUW3fGndXRc9EqkdTkKAgAC7kBA= Date: Wed, 29 Jul 2020 05:38:17 +0000 Message-ID: <16927_1596001099_5F210B4B_16927_206_1_787AE7BB302AE849A7480A190F8B933031506915@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <24352.9444.775247.214537@fireball.acr.fi> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933031506915OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Preliminary minutes from the IETF 108 IPsecME WG Meeting 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, 29 Jul 2020 05:38:24 -0000 --_000_787AE7BB302AE849A7480A190F8B933031506915OPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Yoav, Ben, all, =3D=3D Ben (AD): (missed first point Belongs in ADD?) Slide with attribute format,= for DoH, need to provide URI template Valery: Presentation also requested in ADD, but didn't have room in agenda.= Re: URI, will be covered in DoH clarifications (?) =3D=3D Valery was referring to https://tools.ietf.org/html/draft-btw-add-rfc8484-c= larification-02#section-6.1 where we define a well-known uri that will be u= sed to retrieve the uri templates directly from the discovered Encrypted se= rver. We that approach, we don't need to supply the URI template in the IKE= attribute. Cheers, Med De : IPsec [mailto:ipsec-bounces@ietf.org] De la part de Yoav Nir Envoy=E9 : mardi 28 juillet 2020 22:22 =C0 : Tero Kivinen Cc : ipsec@ietf.org Objet : Re: [IPsec] Preliminary minutes from the IETF 108 IPsecME WG Meeting Hi. I uploaded a PDF version to the meeting materials. Also added a list of act= ion items for the chairs. Comments are welcome on that part as well. https://www.ietf.org/proceedings/108/minutes/minutes-108-ipsecme-00 Yoav On 28 Jul 2020, at 16:15, Tero Kivinen > wrote: Here is preliminary minues from the IETF 108 IPsecME WG meeting. I copied some discussion about the proposed changes to ESP from Jabber to here, as I think it was important to record those even when we did not have time to have comments during the meeting. If you have any comments, please send them to me as soon as possible. ---------------------------------------------------------------------- # IPsecME IETF 108 Time: Tuesday, 28-Jul-2020, at 11:00-12:40 UTC ## Agenda: * 11:00-11:05 - Note Well, technical difficulties and agenda bashing * 11:05-11:10 - Document status (chairs) * 11:10-11:25 - draft-smyslov-ipsecme-rfc8229bis (Valery/Tommy) * 11:25-11:35 - draft-btw-add-ipsecme-ike-00 (Valery) * 11:35-11:45 - draft-smyslov-ipsecme-ikev2-auth-announce (Valery) * 11:45-12:00 - Proposed improvements to ESP (Michael Rossberg) * 12:00-12:15 - IPTFS (Christian Hopps) * 12:15-12:30 - YANG model for IPTFS (Christian Hopps) * 12:30-12:40 - AOB + Open Mic ### Note Well, technical difficulties and agenda bashing *Chairs* (5min) No Edits ### Document status *chairs* (5min) *-implicit-Iv published as RFC8750 *-qr-ikev2 published as RFC8784 *-ipv6-ipv4-codes publication requested ### draft-smyslov-ipsecme-rfc8229bis (TCP encap of IKE/IPsec) *Valery/Tommy* (15min) Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme= -rfc8229bis-00 Paul Wouters: What are the kernel implications? And does this allow for sma= ller IPsec/ESP Packets? Valery: Text is a bit short, TCP stream packets will have same class Paul: What Interop testing has been done? Valery: Tested with Apple, Cisco, libreswan Piannissimo Hum for who has read the draft Paul: Good idea to adopt, found issues that would be good to incorporate in= draft Yoav: Will take to list if we need an update to 8229 and if this is the rig= ht starting point. ### draft-btw-add-ipsecme-ike-00 (IKEv2 config for Encrypted DNS) *Valery* (10min) Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme= -ikev2-configuration-for-encrypted-dns-00 Paul: What to do outside of VPN tunnel seems out of scope? (regarding Scope= bit) Valery: Still an interesting subject Ben (AD): (missed first point Belongs in ADD?) Slide with attribute format,= for DoH, need to provide URI template Valery: Presentation also requested in ADD, but didn't have room in agenda.= Re: URI, will be covered in DoH clarifications (?) Ben: When DoQ arrives may need additional work Tero: Add configuration attributes, less internal strucutre, more higher le= vel structure Yoav (participant): Missing motivation from draft Moving towards encrypted= world, don't want to force people to keep insecure DNS just for legacy IKE= v2 server Valery: That is one of the motivations; users won't see this, but it is use= ful. Tirumaleswar Reddy: URL can be discovered another way Benedict Wong: My understanding is that in some cases we need a hostname to= do validation of the DoT server Tirumaleswar: This only supports PKI-based verification, so we can verify b= ased on sent certificate. Yoav: Calling for adoption? Valery: ADD Primary target for adoption, ipsecme is just informational, if = there is interest it could persist in this WG, but not yet. Tirumaleswar: Couple more revisions necessary, extension to IKE, want to ma= ke sure both working groups are aware of work Ben (AD): If ipsecme was concerned by the work, or on the other hand thinks= it makes sense, it's good information for ADD to have ### draft-smyslov-ipsecme-ikev2-auth-announce *Valery* (10min) Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme= -announcing-supported-authentication-methods-in-ikev2-00 Paul: Good idea, unclear where complexity might be, in the past migration b= etween methods (null -> something else) needed a ppk hack - sending two aut= h payloads Tero (participant): Could have one part negotiate the algorithm, and the se= cond part to negotiate the algorithm ids for CAs in the certreq Yoav: will take a call for adoption to the list ### Proposed improvements to ESP *Michael Rossberg* (15min) Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme= -proposed-improvements-to-esp-01 Yoav (?): Discussion happening on list and in jabber. Informational would = be wrong, changes packet on wire, so experimental or standards track if any= thing Summary of questions and comments from the jabber: * Yoav: Some firewalls would be very upset about this packet format, becaus= e it looks like every packet is retransmission. * Paul: so flip sender/window id with sequence number * Chopps: andeven put the higher order after lower order so stays exactly t= he same as before * Scott Fluhrer: In addition, each sending id/window id has its own replay = window, does that mean that the receiver needs to track 4 billion antirepla= y windows? * Scott: Also, it wouldn't be secure with CBC * Paul: It drops all non-AEAD, which we should do anyways * Scott: You also lose the multitarget protection with GCM by not including= the 32 bits of key-derived nonce * chopps: The sender id is really a mcast thing, so it reduces to 64k * Scott: Does the receiver need to track a antireplay window for each multi= cast sender? * Yaov: Yes * Scott: I can't see how that can work on a decryptor that can't dynamicall= y allocate memory * Bob Moskowitz: Would need a change to robust header compression so that s= maller seq# for constrained links? * Valery: This proposal lacks enough generality to replace ESP - it conside= rs very small set of ciphers and use cases * Paul: and we might as well throw in a discussion of implicit IV if we are= updating ESP to v4 * Yoav: @Valery: doesn't it use all the ciphers that people care about now?= Consider that TLS 1.3 has about two ciphers (plus another 1 for IOT). * Valery: In addition, many things it aims for can be achieved using ESP. E= ven replay protection for multicast (with some limitations). * Steffen Klassert: Get rid of the trailer would be nice from implementatio= n point of view * Valery: @yoav, No, it doesn't work with CBC at all. Moreover, if IV is so= mehow structured, it won't work too * Yoav: TLS 1.3 doesn't support CBC either. * Valery: I understand, but what if tomorrow a new cipher mode appear that = is superior to GCM and will require some special form of IV? The problem is= that this design requires IV to be in a particular form. If cipher require= s other form, it'll fail Tero: Not in charter, this is a big change. See if it is a good idea first= before taking to much time discussing and writing ### IPTFS -- [draft-ietf-ipsecme-iptfs-01](https://tools.ietf.org/html/draf= t-ietf-ipsecme-iptfs-01) *Christian Hopps* (15min) Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme= -ip-traffic-flow-security-00 Yoav: Hasn't gotten much review, WGLC is one way, but don't know if it is t= he best way. Requesting transport area early may be a good way too. Tero: Might be hard to get another protocol number. Lou: Getting a protocol number shouldn't be a big deal; many can be depreca= ted. Ben: Please fill out the official early-allocation form request. Agreed on sending this out for transport area early review. ### YANG model for IPTFS -- [draft-fedyk-ipsecme-yang-iptfs-00](https://too= ls.ietf.org/html/draft-fedyk-ipsecme-yang-iptfs-00) *Christian Hopps* (15min) Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme= -yang-model-for-ip-traffic-flow-security-00 Tero: SDN YANG models generally work in two mode, either IKE-less, where it= configures IPsec SAs, or in IKE mode where it does not touch IPsec SAs, as= IKE configures them, so they wanted to keep the configuration clear which = parts they are configuring. Christian: Also operational state, even if not configured via YANG Tero: If we could consolidate on a single YANG model, that would be ideal (= such as I2NFS) Yoav: Per chat, would benefit from a YANG Dr. review Lou: Would benefit from another review, per datatracker, latest draft needs= another review. ### AOB + Open Mic *all* (10min) Paul: Labeled IPsec still in review. Graveyard draft still in limbo Tero: Take to list; a few of these can go to WGLC, but should check with AD= first. Tero: I think we need to have interm meeting about the ESP. We cut the disc= ussion out from here, as it would have taken the rest of the time, but we s= hould have separate interm just for it. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_787AE7BB302AE849A7480A190F8B933031506915OPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Yoav, Ben, all,

 

=3D= =3D

Ben = (AD): (missed first point Belongs in ADD?) Slide with attribute format, for= DoH, need to provide URI template

Vale= ry: Presentation also requested in ADD, but didn’t have room in agend= a. Re: URI, will be covered in DoH clarifications (?)

=3D= =3D

 

Vale= ry was referring to https://tools.ietf.org/html/draft-btw-add-rfc8484-clarification-02#section-= 6.1 where we define a well-known uri that will be used to retrieve the = uri templates directly from the discovered Encrypted server. We that approa= ch, we don’t need to supply the URI template in the IKE attribute.

 

Chee= rs,

Med<= o:p>

 

De : IPsec [mailto:ipsec-bounce= s@ietf.org] De la part de Yoav Nir
Envoy=E9 : mardi 28 juillet 2020 22:22
=C0 : Tero Kivinen <kivinen@iki.fi>
Cc : ipsec@ietf.org
Objet : Re: [IPsec] Preliminary minutes from the IETF 108 IPsec= ME WG Meeting

 

Hi.

 

I uploaded a PDF version to the meeting materials. A= lso added a list of action items for the chairs.  Comments are welcome= on that part as well.

 

 

Yoav



On 28 Jul 2020, at 16:15, Tero Kivinen <kivinen@iki.fi> wrote:

 

Here is preliminary minues from the IETF 108 IPsecME= WG meeting. I
copied some discussion about the proposed changes to ESP from Jabber
to here, as I think it was important to record those even when we did
not have time to have comments during the meeting.

If you have any comments, please send them to me as soon as possible.
----------------------------------------------------------------------
# IPsecME IETF 108

Time: Tuesday, 28-Jul-2020, at 11:00-12:40 UTC

## Agenda:
* 11:00-11:05 - Note Well, technical difficulties and agenda bashing
* 11:05-11:10 - Document status (chairs)
* 11:10-11:25 - draft-smyslov-ipsecme-rfc8229bis (Valery/Tommy)
* 11:25-11:35 - draft-btw-add-ipsecme-ike-00 (Valery)
* 11:35-11:45 - draft-smyslov-ipsecme-ikev2-auth-announce (Valery)
* 11:45-12:00 - Proposed improvements to ESP (Michael Rossberg)
* 12:00-12:15 - IPTFS (Christian Hopps)
* 12:15-12:30 - YANG model for IPTFS (Christian Hopps)
* 12:30-12:40 - AOB + Open Mic

### Note Well, technical difficulties and agenda bashing
*Chairs* (5min)

No Edits

### Document status
*chairs* (5min)

*-implicit-Iv published as RFC8750
*-qr-ikev2 published as RFC8784

*-ipv6-ipv4-codes publication requested

### draft-smyslov-ipsecme-rfc8229bis (TCP encap of IKE/IPsec)
*Valery/Tommy* (15min)

Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-rfc8229bis-0= 0

Paul Wouters: What are the kernel implications? And does this allow for sma= ller IPsec/ESP Packets?
Valery: Text is a bit short, TCP stream packets will have same class
Paul: What Interop testing has been done?
Valery: Tested with Apple, Cisco, libreswan

Piannissimo Hum for who has read the draft

Paul: Good idea to adopt, found issues that would be good to incorporate in= draft

Yoav: Will take to list if we need an update to 8229 and if this is the rig= ht starting point.

### draft-btw-add-ipsecme-ike-00 (IKEv2 config for Encrypted DNS)
*Valery* (10min)

Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-ikev2-config= uration-for-encrypted-dns-00

Paul: What to do outside of VPN tunnel seems out of scope? (regarding Scope= bit)

Valery: Still an interesting subject

Ben (AD): (missed first point Belongs in ADD?) Slide with attribute format,= for DoH, need to provide URI template

Valery: Presentation also requested in ADD, but didn't have room in agenda.=  Re: URI, will be covered in DoH clarifications (?)

Ben: When DoQ arrives may need additional work

Tero: Add configuration attributes, less internal strucutre, more higher le= vel structure

Yoav (participant): Missing motivation from draft  Moving towards encr= ypted world, don't want to force people to keep insecure DNS just for legac= y IKEv2 server

Valery: That is one of the motivations; users won't see this, but it is use= ful.

Tirumaleswar Reddy: URL can be discovered another way

Benedict Wong: My understanding is that in some cases we need a hostname to= do validation of the DoT server

Tirumaleswar: This only supports PKI-based verification, so we can verify b= ased on sent certificate.

Yoav: Calling for adoption?

Valery: ADD Primary target for adoption, ipsecme is just informational, if = there is interest it could persist in this WG, but not yet.

Tirumaleswar: Couple more revisions necessary, extension to IKE, want to ma= ke sure both working groups are aware of work

Ben (AD): If ipsecme was concerned by the work, or on the other hand thinks= it makes sense, it's good information for ADD to have

### draft-smyslov-ipsecme-ikev2-auth-announce
*Valery* (10min)

Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-announcing-s= upported-authentication-methods-in-ikev2-00

Paul: Good idea, unclear where complexity might be, in the past migration b= etween methods (null -> something else) needed a ppk hack - sending two = auth payloads

Tero (participant): Could have one part negotiate the algorithm, and the se= cond part to negotiate the algorithm ids for CAs in the certreq

Yoav: will take a call for adoption to the list

### Proposed improvements to ESP
*Michael Rossberg* (15min)

Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-proposed-imp= rovements-to-esp-01

Yoav (?): Discussion happening on list and in jabber.  Informational w= ould be wrong, changes packet on wire, so experimental or standards track i= f anything

Summary of questions and comments from the jabber:

* Yoav: Some firewalls would be very upset about this packet format, becaus= e it looks like every packet is retransmission.
* Paul: so flip sender/window id with sequence number
* Chopps: andeven put the higher order after lower order so stays exactly t= he same as before
* Scott Fluhrer: In addition, each sending id/window id has its own replay = window, does that mean that the receiver needs to track 4 billion antirepla= y windows?
* Scott: Also, it wouldn't be secure with CBC
* Paul: It drops all non-AEAD, which we should do anyways
* Scott: You also lose the multitarget protection with GCM by not including= the 32 bits of key-derived nonce
* chopps: The sender id is really a mcast thing, so it reduces to 64k
* Scott: Does the receiver need to track a antireplay window for each multi= cast sender?
* Yaov: Yes
* Scott: I can't see how that can work on a decryptor that can't dynamicall= y allocate memory
* Bob Moskowitz: Would need a change to robust header compression so that s= maller seq# for constrained links?
* Valery: This proposal lacks enough generality to replace ESP - it conside= rs very small set of ciphers and use cases
* Paul: and we might as well throw in a discussion of implicit IV if we are= updating ESP to v4
* Yoav: @Valery: doesn't it use all the ciphers that people care about now?= Consider that TLS 1.3 has about two ciphers (plus another 1 for IOT).
* Valery: In addition, many things it aims for can be achieved using ESP. E= ven replay protection for multicast (with some limitations).
* Steffen Klassert: Get rid of the trailer would be nice from implementatio= n point of view
* Valery: @yoav, No, it doesn't work with CBC at all. Moreover, if IV is so= mehow structured, it won't work too
* Yoav: TLS 1.3 doesn't support CBC either.
* Valery: I understand, but what if tomorrow a new cipher mode appear that = is superior to GCM and will require some special form of IV? The problem is= that this design requires IV to be in a particular form. If cipher require= s other form, it'll fail

Tero: Not in charter, this is a big change.  See if it is a good idea = first before taking to much time discussing and writing

### IPTFS -- [draft-ietf-ipsecme-iptfs-01](https://tools.ietf.org/html/draft-ietf-= ipsecme-iptfs-01)
*Christian Hopps* (15min)

Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-ip-traffic-f= low-security-00

Yoav: Hasn't gotten much review, WGLC is one way, but don't know if it is t= he best way. Requesting transport area early may be a good way too.

Tero: Might be hard to get another protocol number.

Lou: Getting a protocol number shouldn't be a big deal; many can be depreca= ted.

Ben: Please fill out the official early-allocation form request.

Agreed on sending this out for transport area early review.

### YANG model for IPTFS -- [draft-fedyk-ipsecme-yang-iptfs-00](https://tool= s.ietf.org/html/draft-fedyk-ipsecme-yang-iptfs-00)
*Christian Hopps* (15min)

Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-yang-model-f= or-ip-traffic-flow-security-00

Tero: SDN YANG models generally work in two mode, either IKE-less, where it= configures IPsec SAs, or in IKE mode where it does not touch IPsec SAs, as= IKE configures them, so they wanted to keep the configuration clear which = parts they are configuring.

Christian: Also operational state, even if not configured via YANG

Tero: If we could consolidate on a single YANG model, that would be ideal (= such as I2NFS)

Yoav: Per chat, would benefit from a YANG Dr. review

Lou: Would benefit from another review, per datatracker, latest draft needs= another review.

### AOB + Open Mic
*all* (10min)

Paul: Labeled IPsec still in review. Graveyard draft still in limbo

Tero: Take to list; a few of these can go to WGLC, but should check with AD= first.

Tero: I think we need to have interm meeting about the ESP. We cut the disc= ussion out from here, as it would have taken the rest of the time, but we s= hould have separate interm just for it.
--
kivinen@iki.fi

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

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_787AE7BB302AE849A7480A190F8B933031506915OPEXCAUBMA2corp_-- From nobody Tue Jul 28 23:23:49 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7C53A101D for ; Tue, 28 Jul 2020 23:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 Ukk8Wa5oPN1b for ; Tue, 28 Jul 2020 23:23:45 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 961233A101B for ; Tue, 28 Jul 2020 23:23:45 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id b25so23766196ljp.6 for ; Tue, 28 Jul 2020 23:23:45 -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=Mj7PzYW78vkuDb35exaZZ+BY9pU1LMc70CdWCDWIrD8=; b=dAPHf55IjKZ/ZpGhyRKSM+dv38Si/eqzAZR2/vSuOnnBFsw1zC721S6SaDJRN0KpD/ BrPTHj9S2KWcNnVXr4BORzEMC2uZGqF76JwriW/YLvzwZ81fC6C0SVLI4D69r5TI9tW/ D4fW4fi1/Kcx0m2brOTo+c6a+ZwtxHUJEaQYTv3ILEUTMPEB9srySCGJw6FjNM6Ii+/4 4x0nySQHcMCdENL3hMK0BA4UunSyLANKyERAIM5sT6GWlTbRrobHMrFaC3zQFIL96Hbe W0ML3FHV+uD9iyTzkfaywqbGmbmF5bak5Iu0otXKgUjwcG9oztsVVpemJBWZh4Qal5Sv bFDA== 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=Mj7PzYW78vkuDb35exaZZ+BY9pU1LMc70CdWCDWIrD8=; b=LSHtgdRDTw1B3crCdN2gdraUnSsxGt+Exdus2dsQMrt4VVKAE3tv3rs56S1VF0dEZz OgiRW/j8HkFw9o8q3rYi8Dl+8HL7yQKDPae2ESBbqitVadzDxVISid2juob0jC7hYUTq TT56MStaKMiYXS9UUCM0rQuV1oC/SiTktpRClHcHPCj2577sTUSrCouAgbMUy1m+ryFq w+LSATwTwCEBsU5KuUk5BYK89G1taPQoK8gSnZa9Bdi3HTzPor/lDq9lNx2h6fBkUmlt Ds+ZBGGj7PFy4Tbohy9A9GVIgHIUhUB8lUayiDrFb6H1jNIOw5oCJGSoVp5INasf5Isu U12Q== X-Gm-Message-State: AOAM5314kNwEwrK36sOPTFZxzn49j3icsKLsRNSGN29o2hYRLYuU2Lgh 2LqAb+iILHSxhKNCvNh1Pq5OSXw8 X-Google-Smtp-Source: ABdhPJyj+WHV1L7OZ8TtY3jGv9bX1XUHnBhJSDwRdhnxlibbNaJPQm0pCvrZ2DlPz8xFdMNUWgM3JQ== X-Received: by 2002:a2e:9746:: with SMTP id f6mr14831539ljj.68.1596003823452; Tue, 28 Jul 2020 23:23:43 -0700 (PDT) Received: from buildpc ([82.138.51.3]) by smtp.gmail.com with ESMTPSA id v16sm201090ljd.1.2020.07.28.23.23.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jul 2020 23:23:42 -0700 (PDT) From: "Valery Smyslov" To: "'Michael Rossberg'" , "'Yoav Nir'" Cc: , "'William Allen Simpson'" References: <023E45E1-B1AA-4042-A8E3-DD7457235BC7@tu-ilmenau.de> <79E51232-5BEF-4B8C-8772-6305559732AE@gmail.com> In-Reply-To: Date: Wed, 29 Jul 2020 09:23:44 +0300 Message-ID: <120e01d66570$cf76cbe0$6e6463a0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLb8KjJ82/eUG4ib/oDCzGyVFFVxgG4NAWZAm+QbvoCi2rJxwDR6doYptbU3xA= Content-Language: ru Archived-At: Subject: Re: [IPsec] Teaser for pitch talk at IETF 108 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, 29 Jul 2020 06:23:47 -0000 Hi Michael, > > The advantage of multiple SAs is that you don=E2=80=99t really need = to change the other side of the IPsec connection > (especially if the peer already supports 6311). So if you have 30 = cluster members, or 30 CPUs, or 30 virtual > LANs, or 30 QoS classes, you can generate 30 SAs rather than 30 = windows within 1 SA. > > > > An SA is rather cheap: It requires a value out of a 32-bit space. = It requires at a minimum saving the key and > current counter. Usually also a 64-bit replay bitmap at the receiver. = Add metadata and we=E2=80=99re talking about a > few dozen bytes. Add an expanded key for performance, and = we=E2=80=99re still under a kilobyte. > > > > I=E2=80=99m not saying it=E2=80=99s a better design, but a new = design should come with an explanation of why it=E2=80=99s better. >=20 > A key advantage of the replay window approach is that there is no need = to setup every window proactively. > That is there is no overhead at all as long as a replay window is not = used. In a multicast environment it would > require reliably pushing a key to every possible sender, which may = become a fairly large group. That is IMHO > a non-negligible overhead. You can get replay protection in multicast environment using unmodified = ESP and modified receiver's logic (with the same limitations as in your design). You don't need multiple = SAs (one per sender). All you need to do - allow GMs to know where to look for Sender ID, = which is located in the higher=20 order bits of IV. Of course, it will only work with counter-based = ciphers, (as well as in your proposal). > We could also solve this by adding some kind of associated SA that is = automatically set up on-demand, but > then > we need to subdivide the SPI space somehow. As Valery and William are = =E2=80=9Cunhappy" with only 16-bit sender > IDs > (perhaps for a good reason), we would require larger SPI fields... Just for clarification - I'm not unhappy with 16-bit (in fact I think = it's enough in _most_ cases), I'm unhappy with this limit hardcoded into the design. Regards, Valery. From nobody Tue Jul 28 23:54:57 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43DF3A0CC5 for ; Tue, 28 Jul 2020 23:54:54 -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 Mi8ZbjoyaF5Y for ; Tue, 28 Jul 2020 23:54:52 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 444F23A1049 for ; Tue, 28 Jul 2020 23:54:52 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id q4so23870609lji.2 for ; Tue, 28 Jul 2020 23:54:52 -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=JcQxKLaYbA8ipdXp/e1A/nV6hrhShnqncw9xKt4jmdQ=; b=Gxjvu9bhLLg9YcQIsQKVGQJGkyocKYVbq5uTTDRPT4IdV59D/mKvxP8nRfSuQtQ+V+ OUYSpDeBw3qSb0XtOhfpJ/ky3xY8HSSryQ9tqScZNyTL0oY6C2xmHj5b9Mf5jg7E+o4G 8kEmReDtnEOavo0UwTJp55w5WI0Qi8zovsEkGWIGvLXrzGhcT0rd/CGt0rJxr7VC9J7m cwmfaON5LG56dtNM2tx9dDG5l18ITLXhzJvBoIkfyuY5tcupO+6jN/igjP/LjqXMulqT FRMD+ANlNz/DW4bLyLowERJLPYqt4bJm0ykqd1ucvt41MPt7+c2sLpLrf/N+qIV3mu5c JYYQ== 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=JcQxKLaYbA8ipdXp/e1A/nV6hrhShnqncw9xKt4jmdQ=; b=tVyVva7ZvCbJWBJV1pz9GGiS3A/osjUYGjqJENGUjFcy/dj2BCF5eWeLO5rJ2JaTFC q8ruQ8EOyrF9vI7ZikfOQoy/ORavOB2j7pnMQYX8Am57Eqb7ml+g/HSWOz3bjEhvP3Hn hQbZ+71P3kJb+2396kEZL1VBDXM5Imu8KSfjysPLdSwdRoGRbB/JXTx3c3eI1Kv2hHyq fW/KLmZY30Uk84spJ+uqHULXD+dv1241Zu1qMNcf71Sd8BiQTwDWBbA3fdanlX87RY4z HnXasyTLv57vfh1jTiIU4ns2W7DsjLlo6VxaZKuhzhQtOjZ6uQIjDXqdbgYUUINto1RC 2VoA== X-Gm-Message-State: AOAM532mrmMdyc57FapNJHxrpTOpRDrXDU072lTKBIZUZ2cvo8LD0u0l z19pfnGED/41FIy/5jzqEiOkrhZj X-Google-Smtp-Source: ABdhPJzv3/Zg/zgYIoxdvgyb9WeOOQRG8OD5E72GAv8Hhtdihc6YKNs5VcVbanfATxwMZwmFkPdVZw== X-Received: by 2002:a2e:6e06:: with SMTP id j6mr5452405ljc.431.1596005688317; Tue, 28 Jul 2020 23:54:48 -0700 (PDT) Received: from buildpc ([82.138.51.3]) by smtp.gmail.com with ESMTPSA id j17sm244719lfr.32.2020.07.28.23.54.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jul 2020 23:54:47 -0700 (PDT) From: "Valery Smyslov" To: "'Tero Kivinen'" , References: <24352.9444.775247.214537@fireball.acr.fi> In-Reply-To: <24352.9444.775247.214537@fireball.acr.fi> Date: Wed, 29 Jul 2020 09:54:49 +0300 Message-ID: <122101d66575$27287470$75795d50$@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: AQInefrQBTpZenNP/fPozA2vH2E+dah79V5w Content-Language: ru Archived-At: Subject: Re: [IPsec] Preliminary minutes from the IETF 108 IPsecME WG Meeting 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, 29 Jul 2020 06:54:56 -0000 Hi Tero, > Paul: What Interop testing has been done? > Valery: Tested with Apple, Cisco, libreswan Just for clarification (sorry it wasn't spelled out well at the session) - by "tested" here I meant that these interop tests were performed with us (ELVIS-PLUS), probably more vendors tested between themselves. Regards, Valery. > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Tero Kivinen > Sent: Tuesday, July 28, 2020 4:15 PM > To: ipsec@ietf.org > Subject: [IPsec] Preliminary minutes from the IETF 108 IPsecME WG Meeting > > Here is preliminary minues from the IETF 108 IPsecME WG meeting. I > copied some discussion about the proposed changes to ESP from Jabber > to here, as I think it was important to record those even when we did > not have time to have comments during the meeting. > > If you have any comments, please send them to me as soon as possible. > ---------------------------------------------------------------------- > # IPsecME IETF 108 > > Time: Tuesday, 28-Jul-2020, at 11:00-12:40 UTC > > ## Agenda: > * 11:00-11:05 - Note Well, technical difficulties and agenda bashing > * 11:05-11:10 - Document status (chairs) > * 11:10-11:25 - draft-smyslov-ipsecme-rfc8229bis (Valery/Tommy) > * 11:25-11:35 - draft-btw-add-ipsecme-ike-00 (Valery) > * 11:35-11:45 - draft-smyslov-ipsecme-ikev2-auth-announce (Valery) > * 11:45-12:00 - Proposed improvements to ESP (Michael Rossberg) > * 12:00-12:15 - IPTFS (Christian Hopps) > * 12:15-12:30 - YANG model for IPTFS (Christian Hopps) > * 12:30-12:40 - AOB + Open Mic > > ### Note Well, technical difficulties and agenda bashing > *Chairs* (5min) > > No Edits > > ### Document status > *chairs* (5min) > > *-implicit-Iv published as RFC8750 > *-qr-ikev2 published as RFC8784 > > *-ipv6-ipv4-codes publication requested > > ### draft-smyslov-ipsecme-rfc8229bis (TCP encap of IKE/IPsec) > *Valery/Tommy* (15min) > > Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-rfc8229bis-00 > > Paul Wouters: What are the kernel implications? And does this allow for smaller IPsec/ESP Packets? > Valery: Text is a bit short, TCP stream packets will have same class > Paul: What Interop testing has been done? > Valery: Tested with Apple, Cisco, libreswan > > Piannissimo Hum for who has read the draft > > Paul: Good idea to adopt, found issues that would be good to incorporate in draft > > Yoav: Will take to list if we need an update to 8229 and if this is the right starting point. > > ### draft-btw-add-ipsecme-ike-00 (IKEv2 config for Encrypted DNS) > *Valery* (10min) > > Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-ikev2-configuration-for- > encrypted-dns-00 > > Paul: What to do outside of VPN tunnel seems out of scope? (regarding Scope bit) > > Valery: Still an interesting subject > > Ben (AD): (missed first point Belongs in ADD?) Slide with attribute format, for DoH, need to provide URI > template > > Valery: Presentation also requested in ADD, but didn't have room in agenda. Re: URI, will be covered in DoH > clarifications (?) > > Ben: When DoQ arrives may need additional work > > Tero: Add configuration attributes, less internal strucutre, more higher level structure > > Yoav (participant): Missing motivation from draft Moving towards encrypted world, don't want to force > people to keep insecure DNS just for legacy IKEv2 server > > Valery: That is one of the motivations; users won't see this, but it is useful. > > Tirumaleswar Reddy: URL can be discovered another way > > Benedict Wong: My understanding is that in some cases we need a hostname to do validation of the DoT > server > > Tirumaleswar: This only supports PKI-based verification, so we can verify based on sent certificate. > > Yoav: Calling for adoption? > > Valery: ADD Primary target for adoption, ipsecme is just informational, if there is interest it could persist in > this WG, but not yet. > > Tirumaleswar: Couple more revisions necessary, extension to IKE, want to make sure both working groups are > aware of work > > Ben (AD): If ipsecme was concerned by the work, or on the other hand thinks it makes sense, it's good > information for ADD to have > > ### draft-smyslov-ipsecme-ikev2-auth-announce > *Valery* (10min) > > Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-announcing-supported- > authentication-methods-in-ikev2-00 > > Paul: Good idea, unclear where complexity might be, in the past migration between methods (null -> > something else) needed a ppk hack - sending two auth payloads > > Tero (participant): Could have one part negotiate the algorithm, and the second part to negotiate the > algorithm ids for CAs in the certreq > > Yoav: will take a call for adoption to the list > > ### Proposed improvements to ESP > *Michael Rossberg* (15min) > > Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-proposed-improvements-to-esp- > 01 > > Yoav (?): Discussion happening on list and in jabber. Informational would be wrong, changes packet on wire, > so experimental or standards track if anything > > Summary of questions and comments from the jabber: > > * Yoav: Some firewalls would be very upset about this packet format, because it looks like every packet is > retransmission. > * Paul: so flip sender/window id with sequence number > * Chopps: andeven put the higher order after lower order so stays exactly the same as before > * Scott Fluhrer: In addition, each sending id/window id has its own replay window, does that mean that the > receiver needs to track 4 billion antireplay windows? > * Scott: Also, it wouldn't be secure with CBC > * Paul: It drops all non-AEAD, which we should do anyways > * Scott: You also lose the multitarget protection with GCM by not including the 32 bits of key-derived nonce > * chopps: The sender id is really a mcast thing, so it reduces to 64k > * Scott: Does the receiver need to track a antireplay window for each multicast sender? > * Yaov: Yes > * Scott: I can't see how that can work on a decryptor that can't dynamically allocate memory > * Bob Moskowitz: Would need a change to robust header compression so that smaller seq# for constrained > links? > * Valery: This proposal lacks enough generality to replace ESP - it considers very small set of ciphers and use > cases > * Paul: and we might as well throw in a discussion of implicit IV if we are updating ESP to v4 > * Yoav: @Valery: doesn't it use all the ciphers that people care about now? Consider that TLS 1.3 has about > two ciphers (plus another 1 for IOT). > * Valery: In addition, many things it aims for can be achieved using ESP. Even replay protection for multicast > (with some limitations). > * Steffen Klassert: Get rid of the trailer would be nice from implementation point of view > * Valery: @yoav, No, it doesn't work with CBC at all. Moreover, if IV is somehow structured, it won't work too > * Yoav: TLS 1.3 doesn't support CBC either. > * Valery: I understand, but what if tomorrow a new cipher mode appear that is superior to GCM and will > require some special form of IV? The problem is that this design requires IV to be in a particular form. If cipher > requires other form, it'll fail > > Tero: Not in charter, this is a big change. See if it is a good idea first before taking to much time discussing > and writing > > ### IPTFS -- [draft-ietf-ipsecme-iptfs-01](https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-01) > *Christian Hopps* (15min) > > Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-ip-traffic-flow-security-00 > > Yoav: Hasn't gotten much review, WGLC is one way, but don't know if it is the best way. Requesting transport > area early may be a good way too. > > Tero: Might be hard to get another protocol number. > > Lou: Getting a protocol number shouldn't be a big deal; many can be deprecated. > > Ben: Please fill out the official early-allocation form request. > > Agreed on sending this out for transport area early review. > > ### YANG model for IPTFS -- [draft-fedyk-ipsecme-yang-iptfs-00](https://tools.ietf.org/html/draft-fedyk- > ipsecme-yang-iptfs-00) > *Christian Hopps* (15min) > > Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-yang-model-for-ip-traffic-flow- > security-00 > > Tero: SDN YANG models generally work in two mode, either IKE-less, where it configures IPsec SAs, or in IKE > mode where it does not touch IPsec SAs, as IKE configures them, so they wanted to keep the configuration > clear which parts they are configuring. > > Christian: Also operational state, even if not configured via YANG > > Tero: If we could consolidate on a single YANG model, that would be ideal (such as I2NFS) > > Yoav: Per chat, would benefit from a YANG Dr. review > > Lou: Would benefit from another review, per datatracker, latest draft needs another review. > > ### AOB + Open Mic > *all* (10min) > > Paul: Labeled IPsec still in review. Graveyard draft still in limbo > > Tero: Take to list; a few of these can go to WGLC, but should check with AD first. > > Tero: I think we need to have interm meeting about the ESP. We cut the discussion out from here, as it would > have taken the rest of the time, but we should have separate interm just for it. > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Jul 29 03:05:15 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3674C3A0745 for ; Wed, 29 Jul 2020 03:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6CzKwSkEFO8 for ; Wed, 29 Jul 2020 03:05:02 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [62.96.220.36]) (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 3C0C43A0593 for ; Wed, 29 Jul 2020 03:05:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 5C02620533; Wed, 29 Jul 2020 12:04:59 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6wf9Z-jHpIz; Wed, 29 Jul 2020 12:04:58 +0200 (CEST) Received: from mail-essen-02.secunet.de (mail-essen-02.secunet.de [10.53.40.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by a.mx.secunet.com (Postfix) with ESMTPS id CC82020299; Wed, 29 Jul 2020 12:04:58 +0200 (CEST) Received: from mbx-essen-01.secunet.de (10.53.40.197) by mail-essen-02.secunet.de (10.53.40.205) with Microsoft SMTP Server (TLS) id 14.3.487.0; Wed, 29 Jul 2020 12:04:58 +0200 Received: from gauss2.secunet.de (10.182.7.193) by mbx-essen-01.secunet.de (10.53.40.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Wed, 29 Jul 2020 12:04:58 +0200 Received: by gauss2.secunet.de (Postfix, from userid 1000) id EC5883180625; Wed, 29 Jul 2020 12:04:57 +0200 (CEST) Date: Wed, 29 Jul 2020 12:04:57 +0200 From: Steffen Klassert To: Valery Smyslov CC: 'Michael Rossberg' , Message-ID: <20200729100457.GD20687@gauss3.secunet.de> References: <023E45E1-B1AA-4042-A8E3-DD7457235BC7@tu-ilmenau.de> <0fd501d664b6$fcc8c590$f65a50b0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <0fd501d664b6$fcc8c590$f65a50b0$@gmail.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-ClientProxiedBy: cas-essen-02.secunet.de (10.53.40.202) To mbx-essen-01.secunet.de (10.53.40.197) X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Archived-At: Subject: Re: [IPsec] Teaser for pitch talk at IETF 108 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, 29 Jul 2020 10:05:05 -0000 Hi Valery, a few comments inline. On Tue, Jul 28, 2020 at 11:13:33AM +0300, Valery Smyslov wrote: > Hi, > > a few thoughts about this proposal. ... > > > * 64 bit sequence counters in each header to ease protocol handling and allow for > > replay protection in multicast groups > > This would simplify replay protection logic on receiver, but will waste > 4 bytes on the wire for unicast SAs. We have already the option to send the high sequence number bits when a combined mode algorithm is used. RFC 4303, Section 2.2.1. says: If a combined mode algorithm is employed, the algorithm choice determines whether the high-order ESN bits are transmitted or are included implicitly in the computation. We could just give multicast the same option if it wants to use replay protection. > > * Removing the trailer to ease segment & fragment handling and alignment > > I was told by Linux kernel people that having trailer in ESP is a headache for them. > However, this simplification has its cost: > > 1. Ciphers that require padding cannot be used. I admit that CBC and the like > are out of fashion today, but I don't know which cipher modes will be in fashion tomorrow > and what requirement for padding they will have. > 2. No Next Header field eliminates transport mode (BTW, widely used for multicast!) > and makes it difficult to implement TFC (you can add TFC padding, but you can't send > dummy packets and you can't use IPTFS) Instead of a trailer, an (optional) encrypted header could be used for transport mode, IPTFS etc. That could be | Pad Length | Next Header | Pad to align payload | > > > * Implicit IVs in spirit of RFC 8750 removing the need for AAD > > I don't consider removing AAD is a benefit, since all the AEAD schemes I'm aware of > allow to have AAD. On the other hand, implicit IV is only applicable > to some transforms. I'm not only talking about non counter-based AEAD ciphers, > (like CBC), but even for counter-based AEAD a situation is possible when there is a need > for IV to be somehow structured and not be a plain counter (e.g if you implement key trees). Right, we should always have the option to include an explicit IV as the IV construction depends on the used algorithm. > > > Further details and benchmark results may be found in a paper preprint [1] and a > > presentation [2] we held with at the Linux IPsec Workshop. > > A few more considerations. > > It seems that performance of this proposal depends on ICV size > for the plaintext to be properly aligned. > If ICV is 16 bytes, then plaintext is ideally aligned on 32 bytes, > but if one use 12 byes ICV (e.g. ENCR_AES_GCM_12) > then the plaintext is aligned on 4 bytes, that is even worse > than ESP, where it is for most AEAD transforms aligned on 16 bytes. We could pad a 12 byes ICV up to 16 bytes, but I have to admit that this might not be the best option. > Since this proposal allows only tunnel mode, it will have > larger overhead for small packets. This is partially > compensated by having IV to be implicit... > > And about security. In order to have IV combined with > ESN and sub-windows identifiers this proposal removes secret > salt from the nonce. This may have impact on security. > I'm not a cryptographer, but I believe the impact is not negligible. > On the last CFRG session a draft draft-wood-cfrg-aead-limits was > discussed that calculates limits of data to be safely encrypted > by various AEAD ciphers. The authors claimed that having > secret salt in the nonce increases this limits in case of multi-user > attacks and that the results in the draft are calculated > for this case. If plain AEAD ciphers (with no secret salt) are used > the limits are lower. A secret salt in the nonce would be a new requirement anyway. I've checked RFC 4106 (ESP for GCM) and RFC 7634 (ESP for ChaCha20-Poly1305), both don't require a secret salt. But I'm not sure if the IV construction in this proposal would be always a good choice. As far as I understand, Sender ID is only used with multicast, so will be most likely zero on unicast. Also the replay window ID will have a lot of zero bits on unicast (given that most nodes have much less than 2^16 cpus these days). Steffen From nobody Wed Jul 29 05:57:09 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8AC3A0AA0 for ; Wed, 29 Jul 2020 05:57:07 -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 lUQZVY_1S_Bf for ; Wed, 29 Jul 2020 05:57:04 -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 B86413A0A9F for ; Wed, 29 Jul 2020 05:57:03 -0700 (PDT) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 6A62A1B0028C; Wed, 29 Jul 2020 15:57:01 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1596027421; 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=M2SZOU1pAyyPp6ZeDO2etzFFICb4NEzXpyr8WGD7c6U=; b=v4kF8YnWnFfQK1/JRuf7wtZUNCCKGRsyjcFJ1Q7Jg9b6+QNFpgVG1tIjZzeK8QaS4ktihh rxkBmlk3NqW8MQn7Etg80DQXNQj+DWLjwxXu3MwJN0cBtGwHKsczh7ktvfG/N8isM9OM8b W5fMu6ShRyEUTG4jhyBRr+B31lKAR2iheu1FFYyxUnR95hNDmYsKYboxxf2p8257A1GgzT eDPN9cYd5ndOUEcmq05ZILR2jNnguuydc8zplKl9GzTnA74ILlnp5idET/LAlZDwUcFC92 8BAichK4Zsbqi7WuOhtBntB+/b+GxsjbXgp2RSZzZIPZDYtPrie1pg8mIiyR6A== Received: by fireball.acr.fi (Postfix, from userid 15204) id 2F0D325C0E99; Wed, 29 Jul 2020 15:57:01 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24353.29213.99390.728108@fireball.acr.fi> Date: Wed, 29 Jul 2020 15:57:01 +0300 From: Tero Kivinen To: "Scott Fluhrer \(sfluhrer\)" Cc: "'ipsecme mailing list'" In-Reply-To: References: X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 14 min X-Total-Time: 13 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1596027421; 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=M2SZOU1pAyyPp6ZeDO2etzFFICb4NEzXpyr8WGD7c6U=; b=h+2RKAb3gj/PmXbn8kGH7nVwZFip6ZgGwbCZKz7q5XQGXPFdl8oWg353AYO9sY4UVJRXq9 v2xEj3uCKoFCcuF9UQoLNbdb55Us7tWORgB2i01vCL1XVxxEvWU1fH8Ut0AGiWQNBtBCAz /OyWyf8Maj/CjjJO3VyXEFQg8eSclMbp2aljHQMveCEGxwt0ztJPBFLkxerW4SbgXl/Yrj qNeS4j95x+bENTLqOAeTo3pxETT9E3bn+2k/njgbx+ICuIAO6bVtbfOsc0VE4c7XHV598w 5oYhrezZHcR56JDQUbxyjxVPrgr80Z7aTPyoy3oQSqkbiER53+2rKvrca9ltuA== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1596027421; a=rsa-sha256; cv=none; b=E5npzBGdaKYLIog97opBZ6zzmKmfSAbzNsq3QvB1p2Vhyq5PUvRmgMD+daJCNGx2e77ImT 23EBqy+Vf0JMqIMoaVxcvABycnV62kdIIJfV0cY8EclfQFw9I0BiN2JsSoM6ec/slsM6cK eMtzRC64c61rY3VhHUW/YUoW5cEvxzz0UGfu4aGLM3dXLYIPBy31/qlrx/WrjdbJuOla2B D/xR+rpkkIbMbbe3/2iuS06BMQ+B+EJAMRjLCTlJzi686DxnV6r2BWucw5e/SEvGv69iCz pCRMyGZb6vAL4U/41rhA36HB03cv/i6Gm7gduaoX2Zo2KcMSRbYslzgeHN/WOQ== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: [IPsec] My comments on "Proposed improvements to ESP" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 12:57:07 -0000 Scott Fluhrer \(sfluhrer\) writes: > As for the idea of moving the integrity check value before the > encapsulated packet, well, that idea might help on your platform; > however it strikes me that the advantage would likely be fairly > platform dependent. Yes. In several kernel implementations the packets are formed as mbufs which are linked list of pieces of packets, and in that kind of environments there is easy ways to add/remove bytes to/from start or to/from the end without needing to copy anything. In case you have single big buffer for the whole packet then removing stuff from the end or adding stuff to the end is possible without any copying provided you have enough space in your buffer. Adding stuff to the beginning of the packet might require you to copy the whole packet... Also the need to read (while receiving packet) the ICV is only after you have already decrypted the whole packet (if using AEAD), and want to verify that the value matches. When the ICV is at the end of packet that means it might already be in the cpu cache, as cpu read the last bytes of the packet and the cache line might be big enough to include ICV. If we need to go back to the beginning to read the ICV it might not be in the cache anymore. Anyways I do not think we should be doing to much optimizatin based on the one specific operating system, cpu, or architecture. If we would be doing this from the scratch, then it might be worth of investigating different operating systems, different cpus and see if we can find out what kind of optimizations we can do and how do they affect, but I do not think we want to make too much changes this late for just very small gains (my guess is that moving ICV optimization is not really visible in tests that include actual network). -- kivinen@iki.fi From nobody Wed Jul 29 06:22:32 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1DA63A0B2A for ; Wed, 29 Jul 2020 06:22:22 -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 qsgwOR_qRPYm for ; Wed, 29 Jul 2020 06:22:20 -0700 (PDT) Received: from meesny.iki.fi (meesny.iki.fi [IPv6:2001:67c:2b0:1c1::201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2269C3A0B1F for ; Wed, 29 Jul 2020 06:22:19 -0700 (PDT) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: kivinen) by meesny.iki.fi (Postfix) with ESMTPSA id 66C8F200C3; Wed, 29 Jul 2020 16:22:16 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1596028936; 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=e8kYGXczrOpD12vsWdEaPQm0HJpaIg7Z/S+a0mUi+S8=; b=OGKJNyoLktFEuVai+MBpAs3vwse0QwmInL1zPIKwiHeJ72tUGafvQPrK19Hm+rRm/UQrq9 wdniT3LniKcJnMA6F6azWCWv34AS9yTULcxkBUV+At3YpWHu0DH8e2RKx4ddX+oHMJyDZg 7/x37ZmU8XMYuYBtDbhaXVOHYzUYK/U= Received: by fireball.acr.fi (Postfix, from userid 15204) id 28A0A25C0EE3; Wed, 29 Jul 2020 16:22:15 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24353.30727.115426.454334@fireball.acr.fi> Date: Wed, 29 Jul 2020 16:22:15 +0300 From: Tero Kivinen To: Steffen Klassert Cc: Valery Smyslov , 'Michael Rossberg' , ipsec@ietf.org In-Reply-To: <20200729100457.GD20687@gauss3.secunet.de> References: <023E45E1-B1AA-4042-A8E3-DD7457235BC7@tu-ilmenau.de> <0fd501d664b6$fcc8c590$f65a50b0$@gmail.com> <20200729100457.GD20687@gauss3.secunet.de> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 15 min X-Total-Time: 23 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1596028936; 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=e8kYGXczrOpD12vsWdEaPQm0HJpaIg7Z/S+a0mUi+S8=; b=W4Dmui8Rypk4bvF+7AKiByTb9g1+J+FD1/VChDPYQWdXJ7u3mv+oztzCl9dACnTSC9S7CY e8V+R3uT06DcADBtkLpC9szbQkVWSNzWmiMV3kdYjsrxU8+FfCFRb6+nRNvM1BtrGGZadD 0VfM/SalkuZ7UdSplbEqKhf8oDIsz34= ARC-Seal: i=1; s=meesny; d=iki.fi; t=1596028936; a=rsa-sha256; cv=none; b=Uu62+VVO3q1ECVbgo1ujf7ISzqYzupFjGUmS3IVYl4W85coroUbBlUxnJIvjG1tF9wyPox I6/8KQL+hDul56oVupoDnrBuXieDV39mtekwILVL31ghePMyPi8PTrIz01IzKwe9TRbZwt FfKN8Xz09u/oQ6JnoJ9Vh/6gosik0gw= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [IPsec] Teaser for pitch talk at IETF 108 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, 29 Jul 2020 13:22:29 -0000 Steffen Klassert writes: > We have already the option to send the high sequence number bits > when a combined mode algorithm is used. > > RFC 4303, Section 2.2.1. says: > > If a combined mode algorithm is employed, the algorithm choice determines > whether the high-order ESN bits are transmitted or are included implicitly > in the computation. We do not have any algorithms that use that feature, and we do not have option to negotiate it in IKEv2. We could add new value for transform type 5 (Extended Sequence Numbers) to say that we use extended sequence number, and that we actually transmit the full extended sequence number. > We could just give multicast the same option if it wants to use > replay protection. As others have already pointed out earlier, with multicast the upper layer must make care of replays and dropped packets themselves in any case, so doing that also on the IPsec level does not really provide that much more security. I mean if the multicast protocol run over UDP over IPsec simply has internal sequence number inside the UDP, which will then be authenticated by the IPsec that should be good enough for replay protection. There is issue that in that case attacker could do Denial of Service attack against the IPsec, by replaying packets, and then the IPsec gateway would decrypt and forward them. When using multicast you already need to use SPI, and destination address as your SAD lookup (RFC4303, section 2.1), i.e. use option 2 there. On the other hand you could use the SPI, destination address, and source address to find the replay window and largest sequence number used if you want to do anti-replay protection on multicast SAs so that each sender has separate replay windows. I assume this is not normally done as it would create so much more extra work for keeping track of replay windows for every single sender, and where the benefit is not that big as upper layer protocols usually do have anti-replay built in. > > And about security. In order to have IV combined with > > ESN and sub-windows identifiers this proposal removes secret > > salt from the nonce. This may have impact on security. > > I'm not a cryptographer, but I believe the impact is not negligible. > > On the last CFRG session a draft draft-wood-cfrg-aead-limits was > > discussed that calculates limits of data to be safely encrypted > > by various AEAD ciphers. The authors claimed that having > > secret salt in the nonce increases this limits in case of multi-user > > attacks and that the results in the draft are calculated > > for this case. If plain AEAD ciphers (with no secret salt) are used > > the limits are lower. > > A secret salt in the nonce would be a new requirement anyway. > I've checked RFC 4106 (ESP for GCM) and RFC 7634 (ESP for > ChaCha20-Poly1305), both don't require a secret salt. It is true that they do not need secret salt, but they do have unpredictable salt, which is created by the key derivation step. My understanding was that this proposal did get rid of that salt too: ---------------------------------------------------------------------- 4. Nonce Format The nonce passed to the GCM-AES encryption algorithm has the following layout: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Salt | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initialization Vector | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Nonce Format The components of the nonce are as follows: Salt The salt field is a four-octet value that is assigned at the beginning of the security association, and then remains constant for the life of the security association. The salt SHOULD be unpredictable (i.e., chosen at random) before it is selected, but need not be secret. We describe how to set the salt for a Security Association established via the Internet Key Exchange in Section 8.1. -- kivinen@iki.fi From nobody Wed Jul 29 06:36:47 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B19563A0B1B for ; Wed, 29 Jul 2020 06:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UStZ-IzRDekr for ; Wed, 29 Jul 2020 06:36:44 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [62.96.220.36]) (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 10DD03A0B1A for ; Wed, 29 Jul 2020 06:36:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 9ACE7205A9; Wed, 29 Jul 2020 15:36:41 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDHMeV_O3ySx; Wed, 29 Jul 2020 15:36:41 +0200 (CEST) Received: from mail-essen-02.secunet.de (mail-essen-02.secunet.de [10.53.40.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by a.mx.secunet.com (Postfix) with ESMTPS id 3BE1320080; Wed, 29 Jul 2020 15:36:41 +0200 (CEST) Received: from mbx-essen-01.secunet.de (10.53.40.197) by mail-essen-02.secunet.de (10.53.40.205) with Microsoft SMTP Server (TLS) id 14.3.487.0; Wed, 29 Jul 2020 15:36:40 +0200 Received: from gauss2.secunet.de (10.182.7.193) by mbx-essen-01.secunet.de (10.53.40.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Wed, 29 Jul 2020 15:36:40 +0200 Received: by gauss2.secunet.de (Postfix, from userid 1000) id 7D90E3181096; Wed, 29 Jul 2020 15:36:40 +0200 (CEST) Date: Wed, 29 Jul 2020 15:36:40 +0200 From: Steffen Klassert To: Tero Kivinen CC: 'Michael Rossberg' , , Valery Smyslov Message-ID: <20200729133640.GG27824@gauss3.secunet.de> References: <023E45E1-B1AA-4042-A8E3-DD7457235BC7@tu-ilmenau.de> <0fd501d664b6$fcc8c590$f65a50b0$@gmail.com> <20200729100457.GD20687@gauss3.secunet.de> <24353.30727.115426.454334@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <24353.30727.115426.454334@fireball.acr.fi> User-Agent: Mutt/1.9.4 (2018-02-28) X-ClientProxiedBy: cas-essen-01.secunet.de (10.53.40.201) To mbx-essen-01.secunet.de (10.53.40.197) X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Archived-At: Subject: Re: [IPsec] Teaser for pitch talk at IETF 108 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, 29 Jul 2020 13:36:46 -0000 On Wed, Jul 29, 2020 at 04:22:15PM +0300, Tero Kivinen wrote: > Steffen Klassert writes: > > > > A secret salt in the nonce would be a new requirement anyway. > > I've checked RFC 4106 (ESP for GCM) and RFC 7634 (ESP for > > ChaCha20-Poly1305), both don't require a secret salt. > > It is true that they do not need secret salt, but they do have > unpredictable salt, which is created by the key derivation step. My > understanding was that this proposal did get rid of that salt too: Yes, this proposal removes the unpredictable salt. I did not say it explicitely, but that was part of my critism on how they create the IV in my original mail. From nobody Wed Jul 29 06:58:15 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8593A0B44 for ; Wed, 29 Jul 2020 06:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umf05b3FhN6q for ; Wed, 29 Jul 2020 06:58:11 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [62.96.220.36]) (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 441ED3A0B39 for ; Wed, 29 Jul 2020 06:58:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id B0C152055E; Wed, 29 Jul 2020 15:58:09 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6zkyZAqcVRq; Wed, 29 Jul 2020 15:58:09 +0200 (CEST) Received: from mail-essen-02.secunet.de (mail-essen-02.secunet.de [10.53.40.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by a.mx.secunet.com (Postfix) with ESMTPS id 44FC620299; Wed, 29 Jul 2020 15:58:09 +0200 (CEST) Received: from mbx-essen-01.secunet.de (10.53.40.197) by mail-essen-02.secunet.de (10.53.40.205) with Microsoft SMTP Server (TLS) id 14.3.487.0; Wed, 29 Jul 2020 15:58:09 +0200 Received: from gauss2.secunet.de (10.182.7.193) by mbx-essen-01.secunet.de (10.53.40.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Wed, 29 Jul 2020 15:58:08 +0200 Received: by gauss2.secunet.de (Postfix, from userid 1000) id A8DF33181096; Wed, 29 Jul 2020 15:58:08 +0200 (CEST) Date: Wed, 29 Jul 2020 15:58:08 +0200 From: Steffen Klassert To: Tero Kivinen CC: "Scott Fluhrer (sfluhrer)" , "'ipsecme mailing list'" Message-ID: <20200729135808.GH27824@gauss3.secunet.de> References: <24353.29213.99390.728108@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <24353.29213.99390.728108@fireball.acr.fi> User-Agent: Mutt/1.9.4 (2018-02-28) X-ClientProxiedBy: cas-essen-02.secunet.de (10.53.40.202) To mbx-essen-01.secunet.de (10.53.40.197) X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Archived-At: Subject: Re: [IPsec] My comments on "Proposed improvements to ESP" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 13:58:14 -0000 On Wed, Jul 29, 2020 at 03:57:01PM +0300, Tero Kivinen wrote: > Scott Fluhrer \(sfluhrer\) writes: > > As for the idea of moving the integrity check value before the > > encapsulated packet, well, that idea might help on your platform; > > however it strikes me that the advantage would likely be fairly > > platform dependent. > > Yes. In several kernel implementations the packets are formed as mbufs > which are linked list of pieces of packets, and in that kind of > environments there is easy ways to add/remove bytes to/from start or > to/from the end without needing to copy anything. On Linux both can happen, packets can be constructed with a scatter-gather list or as a single linear buffer. In both cases we have headroom to add headers, but tailroom is not guaranteed. So in most cases we either need to allocate a new scatter-gather list entry for the trailer, or we have to allocate a bigger buffer and to copy the packet data. But yes, it depends on the platform. > In case you have single big buffer for the whole packet then removing > stuff from the end or adding stuff to the end is possible without any > copying provided you have enough space in your buffer. Adding stuff to > the beginning of the packet might require you to copy the whole > packet... We need space to add the headers at the beginning anyways. With the trailer, we need space on both ends. > > Also the need to read (while receiving packet) the ICV is only after > you have already decrypted the whole packet (if using AEAD), and want > to verify that the value matches. When the ICV is at the end of packet > that means it might already be in the cpu cache, as cpu read the last > bytes of the packet and the cache line might be big enough to include > ICV. If we need to go back to the beginning to read the ICV it might > not be in the cache anymore. Right, this is true indeed. From nobody Wed Jul 29 08:47:48 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4153C3A0BE7 for ; Wed, 29 Jul 2020 08:47:46 -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 EJ0NrF5SGLJI for ; Wed, 29 Jul 2020 08:47:43 -0700 (PDT) Received: from smail.rz.tu-ilmenau.de (smail.rz.tu-ilmenau.de [141.24.186.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EC183A0C0A for ; Wed, 29 Jul 2020 08:47:43 -0700 (PDT) Received: from [192.168.2.166] (unknown [93.253.126.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smail.rz.tu-ilmenau.de (Postfix) with ESMTPSA id 212F9580060; Wed, 29 Jul 2020 17:47:41 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_96431E9E-42FB-4A33-8FEA-AA882E03ECDF"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Michael Rossberg In-Reply-To: <0fd501d664b6$fcc8c590$f65a50b0$@gmail.com> Date: Wed, 29 Jul 2020 17:47:39 +0200 Cc: ipsec@ietf.org Message-Id: <24E3826D-7C3C-46A0-A552-DB6CD2005945@tu-ilmenau.de> References: <023E45E1-B1AA-4042-A8E3-DD7457235BC7@tu-ilmenau.de> <0fd501d664b6$fcc8c590$f65a50b0$@gmail.com> To: Valery Smyslov X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [IPsec] Teaser for pitch talk at IETF 108 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, 29 Jul 2020 15:47:47 -0000 --Apple-Mail=_96431E9E-42FB-4A33-8FEA-AA882E03ECDF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >>=20 >> We have been analyzing issues ESP has in current data-center networks = and came to >> the conclusion that changes in the protocol could significantly = improve its behavior. Some >> of results will be presented next Tuesday in a pitch talk at IETF = 108. This mail is just a >> small teaser, in case some of you wanted to gather some arguments for = the discussion. >>=20 >> In particular, we propose the following changes to ESP: >>=20 >> * Allow multiple windows per SA to allow for scaling over CPUs, = windows per QoS >> class & replay protection in multicast groups > 3. If multiple windows are used for several QoS classes, then this = proposal won't work in case > of TCP encapsulation, while several ESP SAs will (if we have = several IKE SAs too). With IPsec in TCP I do not believe one requires QoS anymore =3D) But = honestly one could go the same way. Multicast, CPU steering etc is a non-issue anyways. > Having replay protection in case of multicast is a feature that is not = currently > available in ESP. However, it's easy to add this feature (with the = limitation > that it only will be available if counter mode ciphers are used) by = simply > letting all GMs know the number of SID bits, so that they can guess > Sender ID from the IV. It's very simple modification of G-IKEv2. If you have an explicit IV that is true. If you want implicit IVs, this = approach no longer works. Note rfc 8750 rules out multicast by design. > Having said this, I think that the replay protection for multicast > is not a feature that is absolutely needed. Multicast is performed > over UDP, so application protocols have to deal with packet > replication and loss in any case (when they are used without > IPsec protection). So, while a nice feature to have, I don't think > it's absolutely necessary and if one needed, it can be achieved = without any > modification to ESP with the same limitations as the proposed > solution. I disagree. As people more and more send VXLAN etc over IPsec I am = afraid that there might be side effects that at least I can no longer foresee. I remember = WEP with its non- existing replay protection, an we could replay certain packets that = generate legitimate answers in order to obtain more traffic for cryptanalysis more quickly. >> * Removing the trailer to ease segment & fragment handling and = alignment >=20 > I was told by Linux kernel people that having trailer in ESP is a = headache for them. > However, this simplification has its cost: >=20 > 1. Ciphers that require padding cannot be used. I admit that CBC and = the like > are out of fashion today, but I don't know which cipher modes will = be in fashion tomorrow > and what requirement for padding they will have. You can still pad implicitly (just like in IPTFS) and are not even = limited to 256 bytes. > 2. No Next Header field eliminates transport mode (BTW, widely used = for multicast!) > and makes it difficult to implement TFC (you can add TFC padding, = but you can't send > dummy packets and you can't use IPTFS) We have ideas to save the field for transport mode, but did not want to = stress the teaser too much. Basically we add an encrypted part to the header. >> * Implicit IVs in spirit of RFC 8750 removing the need for AAD >=20 > I don't consider removing AAD is a benefit, since all the AEAD schemes = I'm aware of > allow to have AAD. They are allowed to have AAD, but it will double en/decryption = operations for small packets. > On the other hand, implicit IV is only applicable > to some transforms. I'm not only talking about non counter-based AEAD = ciphers, > (like CBC), but even for counter-based AEAD a situation is possible = when there is a need > for IV to be somehow structured and not be a plain counter (e.g if you = implement key trees). As written in the chat during presentation we could look at that. But it = is always possible to go back to an explicit IV. >> Further details and benchmark results may be found in a paper = preprint [1] and a >> presentation [2] we held with at the Linux IPsec Workshop. >=20 > A few more considerations. >=20 > It seems that performance of this proposal depends on ICV size > for the plaintext to be properly aligned. > If ICV is 16 bytes, then plaintext is ideally aligned on 32 bytes, > but if one use 12 byes ICV (e.g. ENCR_AES_GCM_12) > then the plaintext is aligned on 4 bytes, that is even worse > than ESP, where it is for most AEAD transforms aligned on 16 bytes. Alignment may - depending on the architecture - be a plus. With only a header one can adjust the headroom to have proper alignment. In any of that cases. For the trailer ESP takes care of 4 byte alignment only. For the header one can use the same tricks, but out of the box you only have 4 byte alignment by IP and even worse 2 byte alignment by Ethernet. > Since this proposal allows only tunnel mode, it will have > larger overhead for small packets. This is partially > compensated by having IV to be implicit... We simplified for presentation as said above. Transport mode is still possible with an additional inner header. > And about security. In order to have IV combined with > ESN and sub-windows identifiers this proposal removes secret > salt from the nonce. This may have impact on security. > I'm not a cryptographer, but I believe the impact is not negligible. > On the last CFRG session a draft draft-wood-cfrg-aead-limits was > discussed that calculates limits of data to be safely encrypted > by various AEAD ciphers. The authors claimed that having > secret salt in the nonce increases this limits in case of multi-user > attacks and that the results in the draft are calculated > for this case. If plain AEAD ciphers (with no secret salt) are used > the limits are lower. The salt is a precaution. Just like the numbers in the padding. Nothing you want to build your security upon. NIST GCM document does not mention it. MACsec does not use a salt. > So, on one hand this proposal makes it possible to transfer > larger amount of data with a single key (because you can > combine all the traffic from different QoS classes and > all the CPU cores into one SA, no need to have > several ESP SAs). On the other hand > it simultaneously decreases the limit of data that > can be safely protected with a single key. I do not under stand why the data is reduced. The probability for = internal collisions in GCM is not affected by the proposal. > I think that it's an interesting work, but I don't think it is > a candidate for ESP replacement. The main problems with it > (as I see it from my corner) is that it is not generic enough: > it is optimized for small number of crypto transforms and > use cases. Indeed we concentrate on the ciphers we found predominant today. For low speed connections there is still CBC, we could add it for sake of = completeness. The optimization for a certain use case is true, too. We concentrated on high speed data center SAs, as it is always easy to make things slower = later on =3D) You can make unicast from a multicast-capable protocol, but not vice = versa. If an outcome of this discussion is, this being special purpose solution = for data centers, that would be absolutely fine I guess. --Apple-Mail=_96431E9E-42FB-4A33-8FEA-AA882E03ECDF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEE/ZtCXI3ladZ37VLCzADDFAM3dskFAl8hmhsACgkQzADDFAM3 dskkIxAA0cdK6ZpBQzMnC3KNQu4h7cXSsYgL4tG4tLHdJnjRUIIwr14/+wax/qNo x2nMjDZao1cjZvTy61XRUhr55iQ7EKCpDoqBjE1QqhLwh7gQJzHCKYKZ8UeHdBAR aFuyzuuHm4k0Q3JzSI2bActO3fVpLZQGhpRpy9jsEpQ6YyjB0myD6dIZo6dNNJZf n7nFymKJJM7ip5yd8VcvxvdTvbVHT2ZYjwAdJOafGzxqaQadJkSLWEWAAs6k5vLA d5YAX2Tjpep3PGpwDZ0ptfgQiFRoGm0D0A1pW4Mdv2t2lqf9541oltMyhb9H/Wc1 Xe8eASqMrUFMotLoNdpVhVlZLRyUrlC9D2mSsGFF2XAhNPVH5ihgHYfjcjWm76lX O4/BqKA+aH8xDbgXeIN0nhMVfSWd8SQXAScs/E86PlfF6f7D/AltLhJp1ZZOD9px AGkAqvlXua5Us4UGEk/U9LPBtRDFdZmCNd8ThScgVyjDtm7E/P/6wsauJnrC53sg 3oSfeBOZ2zLYC4404wJ6dIJcKORhXL49ctIlNC1wJgnDKE5tnywwO8HTVolfWHbR qNVCfMmOfD6Fjvj7uGC2H1jldiySt2x7EJfJqFE48wKatamLVZnl/E0RcblkoVHR 5CDXvWRWnD+fp3EtLjsp7fV66m3OerndrMBpL4TWvQgpWGKCIk8= =P/kb -----END PGP SIGNATURE----- --Apple-Mail=_96431E9E-42FB-4A33-8FEA-AA882E03ECDF-- From nobody Wed Jul 29 09:10:44 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51AC03A0BE3 for ; Wed, 29 Jul 2020 09:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmpRJrjqPTDa for ; Wed, 29 Jul 2020 09:10:40 -0700 (PDT) Received: from smail.rz.tu-ilmenau.de (smail.rz.tu-ilmenau.de [141.24.186.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F1E13A0BE7 for ; Wed, 29 Jul 2020 09:10:23 -0700 (PDT) Received: from [192.168.2.166] (unknown [93.253.126.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smail.rz.tu-ilmenau.de (Postfix) with ESMTPSA id 612F7580060; Wed, 29 Jul 2020 18:10:21 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_B946AE02-0EC5-4085-8D3C-B40B05BCCFC5"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Michael Rossberg In-Reply-To: <24353.30727.115426.454334@fireball.acr.fi> Date: Wed, 29 Jul 2020 18:10:20 +0200 Cc: Steffen Klassert , Valery Smyslov , ipsec@ietf.org Message-Id: References: <023E45E1-B1AA-4042-A8E3-DD7457235BC7@tu-ilmenau.de> <0fd501d664b6$fcc8c590$f65a50b0$@gmail.com> <20200729100457.GD20687@gauss3.secunet.de> <24353.30727.115426.454334@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [IPsec] Teaser for pitch talk at IETF 108 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, 29 Jul 2020 16:10:42 -0000 --Apple-Mail=_B946AE02-0EC5-4085-8D3C-B40B05BCCFC5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >> We have already the option to send the high sequence number bits >> when a combined mode algorithm is used. >>=20 >> RFC 4303, Section 2.2.1. says: >>=20 >> If a combined mode algorithm is employed, the algorithm choice = determines >> whether the high-order ESN bits are transmitted or are included = implicitly >> in the computation. >=20 > We do not have any algorithms that use that feature, and we do not > have option to negotiate it in IKEv2. >=20 > We could add new value for transform type 5 (Extended Sequence > Numbers) to say that we use extended sequence number, and that we > actually transmit the full extended sequence number. That would already help for the case. >> We could just give multicast the same option if it wants to use >> replay protection. >=20 > As others have already pointed out earlier, with multicast the upper > layer must make care of replays and dropped packets themselves in any > case, so doing that also on the IPsec level does not really provide > that much more security. I mean if the multicast protocol run over UDP > over IPsec simply has internal sequence number inside the UDP, which > will then be authenticated by the IPsec that should be good enough for > replay protection. >=20 > There is issue that in that case attacker could do Denial of Service > attack against the IPsec, by replaying packets, and then the IPsec > gateway would decrypt and forward them. Like pointed out in the answer to Valery=E2=80=99s mail. There are = possibly more issues, as attackers are able to generate new traffic, they can use for cryptanalysis (see https://www.aircrack-ng.org/doku.php?id=3Darp-request_reinjection). Having anti-replay guarantees is just a reliable foundation. IMHO the case of applications being responsible holds just as well for unicast applications. TCP takes care of that, still no-one honestly discusses removing replay checks for high volume unicast SAs. > When using multicast you already need to use SPI, and destination > address as your SAD lookup (RFC4303, section 2.1), i.e. use option 2 > there. On the other hand you could use the SPI, destination address, > and source address to find the replay window and largest sequence > number used if you want to do anti-replay protection on multicast SAs > so that each sender has separate replay windows. This still requires to know all possible senders beforehand. Also the SAs will still need to agree on an IV subspace and sending an explicit IV per packet. >>> And about security. In order to have IV combined with >>> ESN and sub-windows identifiers this proposal removes secret >>> salt from the nonce. This may have impact on security. >>> I'm not a cryptographer, but I believe the impact is not negligible. >>> On the last CFRG session a draft draft-wood-cfrg-aead-limits was >>> discussed that calculates limits of data to be safely encrypted >>> by various AEAD ciphers. The authors claimed that having >>> secret salt in the nonce increases this limits in case of multi-user >>> attacks and that the results in the draft are calculated >>> for this case. If plain AEAD ciphers (with no secret salt) are used >>> the limits are lower. >>=20 >> A secret salt in the nonce would be a new requirement anyway. >> I've checked RFC 4106 (ESP for GCM) and RFC 7634 (ESP for >> ChaCha20-Poly1305), both don't require a secret salt. >=20 > It is true that they do not need secret salt, but they do have > unpredictable salt, which is created by the key derivation step. My > understanding was that this proposal did get rid of that salt too: Like written already: An unpredictable value of 32bit size is of no real = value from a crypto point of view. One could simply guess the value and have a realistic chance of being right after a couple of thousand tries. I = believe it is only in the standard, as with 64 bit sequence numbers there where 32 = bits left; needing to be filled. --Apple-Mail=_B946AE02-0EC5-4085-8D3C-B40B05BCCFC5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEE/ZtCXI3ladZ37VLCzADDFAM3dskFAl8hn2wACgkQzADDFAM3 dsn3eg//Slv6YmIeyL+odaw5tzI5Fnoj5J/XYdXk8hPYYBc+85qY1TP0siXJAo1H VOoTAt0qiyIyEG47EIkiSZqf1OsN62PG9cpaLBNu6vHDm/2m5BmxFwK7sn38NLio ev6UwyMJ3fF6Vt9eXxS8dTMJJMNdw8DQWpCKQw0hC6k7azKL0sMP2Rc1LiYh45PW dj3fyGmam5kVSF0plrFwB4s1k3iIKMTHWpC/CurRSRWwsZv6De3uPg2Qvc4cNbJo n2VVRuam2wgm+InPAzdg7zhq9JjoohYqEgunnE4gizMQu77ODkZYojj5PXLwqMP2 KWjEwnt3WOTNvil3KnRXprXOGN6+HR1f3L+bD9C2Sgtx/tQz77f07t400SNASSMn vM2PiuTq5FscOcR5S5Uxm4NtKmyXzoLIhqDRQCcWAAkInx0EHiPISZHEb4R+HpyR 2JxEv+eQ+vlcnsj8QnTiZbtocgMU6QqBqqbbwhtm4DvFs9YbZK/f9AZkliMOoCdg FK/GHo85WMsyN/AcNVJaeinAoTjG2JpJSoXb9gmmoz17iffHs5NnY7EsRzAKKLTQ WYK3jLhFl+4Pxfu5J2UqM08w1p7WJr7infxrdazYNHT8dv9RgCQ1r5Dge0Vn5ca8 VKlsndxHYKksKC9kUmzYs/GUIj3OtGwz/Hn3j8RkC9H9+WYQgnk= =xgK4 -----END PGP SIGNATURE----- --Apple-Mail=_B946AE02-0EC5-4085-8D3C-B40B05BCCFC5-- From nobody Wed Jul 29 09:57:17 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 462023A0CCE for ; Wed, 29 Jul 2020 09:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=GFNJfbLQ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=aLsE9Xbs 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 TP1gB841egVV for ; Wed, 29 Jul 2020 09:57:12 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 876883A0CC7 for ; Wed, 29 Jul 2020 09:57:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7904; q=dns/txt; s=iport; t=1596041832; x=1597251432; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=nveX8LAI9BUs5H72QQDkJXWl/Gx8WOZOdu9uYqfntXk=; b=GFNJfbLQEo0PR6aiAyf43aud5gY6roSchh4oW6dhRTW47t62VxdeUls/ +e/u4EN8FFBVrO88Me62Zl/+eCEl443cGE6hDgJRPd/9sMByu78esTlzu f9Lp/UCrMJv1lvxtmx61v/KtJAeCtJdsy/5Xwp7ISibKpVtgo1sH5cYw7 Q=; IronPort-PHdr: =?us-ascii?q?9a23=3Aa5SrqxJ3GxHgdAKqAtmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeGv68/kEKMXIHe5vRNlqzavvOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZXiehjTpni/6zcPXB?= =?us-ascii?q?nyZkJ5I+3vEdvUiMK6n+m555zUZVBOgzywKbN/JRm7t0PfrM4T1IBjMa02jB?= =?us-ascii?q?DOpyhF?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A3AAAEqiFf/5pdJa1GGhsBAQEBAQE?= =?us-ascii?q?BAQUBAQESAQEBAwMBAQFAgTgEAQEBCwGBUVEHb1gvLAqEK4NGA41OigKOX4E?= =?us-ascii?q?ugSUDVQsBAQEMAQEjCgIEAQGETAIXgg0CJDYHDgIDAQELAQEFAQEBAgEGBG2?= =?us-ascii?q?FXAyFcQEBAQECARIREQwBATcBBAcEAgEIEQQBAQMCJgICAh8RFQgIAgQOBQg?= =?us-ascii?q?agwWCSwMOIAEOO6N4AoE5iGF2gTKDAQEBBYUSDQuCDgMGgQ4qAYJug1+DdIE?= =?us-ascii?q?IgSYdGoFBP4ERQ4IfLj6BBIEWQgQXgSQBASIVgn8zgi2PXYMToiYkTgqCX48?= =?us-ascii?q?ahWyFGp90nzSSCwIEAgQFAg4BAQWBWgUugVdwFYMkUBcCDY4eDBeDToUUhUJ?= =?us-ascii?q?0AjUCBgEHAQEDCXyOUQGBEAEB?= X-IronPort-AV: E=Sophos;i="5.75,410,1589241600"; d="scan'208";a="535101497" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Jul 2020 16:57:07 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 06TGv7te000800 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Jul 2020 16:57:07 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 29 Jul 2020 11:57:06 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 29 Jul 2020 12:57:06 -0400 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 29 Jul 2020 12:57:06 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZUwZHulFvqWvIfscyXcs4A7BnJ2KG4J4RMxULQptwbypNG1vNdW7nTsqx3LvGF4NPOqeJnIWzAcwL7y+rOhEHjBPE+ZvzRTiH02zexESWNrkkVK6uLFtY0tTENduID8abMmxmTsctKFUzcUwixUi5TwlavGNmeCKhKm0ru23/3pGvU1ozh3ZlvWiEMdzfFNMph6xnrlOLJ6oAsAOVmTDpEXHVsN89H5m5maISri5urFRUu3du9gC96ldNn92p2iYMTTCb8X+VmXV2DsT2Ixdm0OwCYUrN+/vFnv5JLXLJWhe9nBpChPL1t8Z3JxHw7ong7RLWh6ZRp3hH6kYhf3KvQ== 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=nveX8LAI9BUs5H72QQDkJXWl/Gx8WOZOdu9uYqfntXk=; b=iIUHjsZ+elQkOrIeIa0snq8A/4srKyuyznGb3Ys2RMLrthSRLvzsbWvQMufoZNLSS99k9XJmZ/hWVnZTYG1B1MTIcPupKv0QFUSgYds8djtAjChJWAwy81XuiZtUUAm+ZoYTryUrrqOJVN+E2nE5lJ2QihRmWmAWfcAWIkNmkiPnJLk5xO7Vs4V5zsIIPqHlzRxxk0Raw9OW07UFhfENqQ/sL3I+KWKI6SDk3cwTjZzgwQjHbiYjdZk7Oq1602ZyYrKqyd8C/7vMXfAJnTLDtWF3LsZjKHGAeTQPc0jLxYnnPvB3jeWTAounmZtwbw5iLoUZkBAes63TU+0PYTofnQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nveX8LAI9BUs5H72QQDkJXWl/Gx8WOZOdu9uYqfntXk=; b=aLsE9Xbs+1NlKXCFIm09ysB9HtrgYzNtkiZtWbLuArKXwirNobVgGuczywTAFG1OukmUz6uY3iYGiR4UdZnfl0H6W5ue2L3F2Uc9Ei/FDVsxyd7hvdolptzX+R6dl/7KUB7q/JbfOg6e/Dl5wiTbXmbKH5p8SqbPu1sutEBMrBc= Received: from BN7PR11MB2641.namprd11.prod.outlook.com (2603:10b6:406:b1::25) by BN8PR11MB3715.namprd11.prod.outlook.com (2603:10b6:408:85::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.17; Wed, 29 Jul 2020 16:57:05 +0000 Received: from BN7PR11MB2641.namprd11.prod.outlook.com ([fe80::5018:edeb:b77d:4d65]) by BN7PR11MB2641.namprd11.prod.outlook.com ([fe80::5018:edeb:b77d:4d65%3]) with mapi id 15.20.3216.034; Wed, 29 Jul 2020 16:57:05 +0000 From: "Scott Fluhrer (sfluhrer)" To: Michael Rossberg CC: "'ipsecme mailing list'" Thread-Topic: [IPsec] Teaser for pitch talk at IETF 108 Thread-Index: AQHWYBKzgiV8IDTYWUmmokuEibQdmKkcrdKAgAGxdYCAADcggIAALvYAgAAEYRA= Date: Wed, 29 Jul 2020 16:57:04 +0000 Message-ID: References: <023E45E1-B1AA-4042-A8E3-DD7457235BC7@tu-ilmenau.de> <0fd501d664b6$fcc8c590$f65a50b0$@gmail.com> <20200729100457.GD20687@gauss3.secunet.de> <24353.30727.115426.454334@fireball.acr.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tu-ilmenau.de; dkim=none (message not signed) header.d=none;tu-ilmenau.de; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e25e4c84-886d-439e-6f2d-08d833e06c11 x-ms-traffictypediagnostic: BN8PR11MB3715: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JI3W626PwCP41PPKHmsnvdnnUQvDxuqOiDoVC7xy6xOsFBd5U6CmqT9sdf63mH8O2vkypX6G0eKl4ezeLZ+VbIaTluLe5FZJJT1c9dtZwb4WQmgp7KmNCa3LOOSwdZe2Np03JmV+X9FFWKn/PM5bOe9qmqqOt36WvjbYbVaF6luOAJWvED8YG4LTlEi5ugRgPSSTi6BSLkqxG/E4oZRAs5e560QmUwfH6PT9iWHaWw/o+geGhcV6o24if6TeSZfBuzVTwsxxj4sUUj9heGt70JIlBgjvUC4/vuIDbJrfy4bNZ4kNeG40Htfrm2EvznSq5WbVgqS3DYvb7LJg06WST+eLUNyjpoIAVYiyMgPSISz9jQdqPgzH8gembPyHzCL/7d/zrMHVaq3PFzrHxTApfA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2641.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(396003)(346002)(376002)(366004)(136003)(478600001)(33656002)(83380400001)(9686003)(966005)(6916009)(8936002)(2906002)(4326008)(55016002)(8676002)(71200400001)(5660300002)(6506007)(16799955002)(52536014)(316002)(7696005)(66446008)(64756008)(66556008)(66476007)(76116006)(66946007)(53546011)(26005)(186003)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: EtHJ7ID6ixgC8mp0b0JThDijwweh30Q0vscN36nX/p8D02ZqUok5Pxgf/+5+eCFvrLRXknwuD9eQe2tSpdWu4tj1ZKsCauu8YqKkylzMyQhlStLdgAPBMu/35P6oA/WbJjPON2CB6bSojozzb3YRlRXyRsKFWK2N7NPc46m8lJV1Od9EdRPkvoVQCww/oXAKj4SeofD5WSvYOafDtduCUBS+aqvNPVtYXRPb3h9hlN10cqAX8K5NoGWoe/bRhbg+y7b01gyQNocxC1otsxCWq7l/38Ita+ir81KI0+74P5CwUysoXps0RJByUNhs6gsw4d4b4bett/Q0XzBdQQKNu95aYRl4gwvHk9zcsdBdII1HlQV4AbA6ZI2YN8SLJai7nen7SEvirTTuuNPETWB8s8lwAG6rgh0IWPI+39uaF2ly9IjdZqoMV1NzEXpdn/coiU7BSYLeT9wRJ130p8iqWRjVXNvPn2AbHJ65UlHI6+2xSbLUk5QUc32XpDJCzKc4nZIBSlb4fI1nMbZ6rgJFfRCEDbdXM9ZnVi+EatHaqdERd/purDfyt6pJvDjXBucLKWn8bkAcD+1Qo1bt2fGvSxjkbuelCJAl4ev21S5tvKNgrvnoQ4R/asWj/WP+HiExrGDgE1iw9nDwoQ0TIMeXVA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN7PR11MB2641.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e25e4c84-886d-439e-6f2d-08d833e06c11 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jul 2020 16:57:05.0538 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dl5o89iFFjH8OBDiLXGldL4TKZXfClImPuF1g/DGUq96kAO8CTFSKDo/99exfoMlNZXZO/1K8OG3JOJMsa0VZw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3715 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [IPsec] Teaser for pitch talk at IETF 108 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, 29 Jul 2020 16:57:16 -0000 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IElQc2VjIDxpcHNlYy1ib3Vu Y2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTWljaGFlbCBSb3NzYmVyZw0KPiBTZW50OiBXZWRu ZXNkYXksIEp1bHkgMjksIDIwMjAgMTI6MTAgUE0NCj4gVG86IFRlcm8gS2l2aW5lbiA8a2l2aW5l bkBpa2kuZmk+DQo+IENjOiBTdGVmZmVuIEtsYXNzZXJ0IDxzdGVmZmVuLmtsYXNzZXJ0QHNlY3Vu ZXQuY29tPjsgaXBzZWNAaWV0Zi5vcmc7IFZhbGVyeQ0KPiBTbXlzbG92IDxzbXlzbG92LmlldGZA Z21haWwuY29tPg0KPiBTdWJqZWN0OiBSZTogW0lQc2VjXSBUZWFzZXIgZm9yIHBpdGNoIHRhbGsg YXQgSUVURiAxMDgNCj4gDQo+IA0KPiA+PiBXZSBoYXZlIGFscmVhZHkgdGhlIG9wdGlvbiB0byBz ZW5kIHRoZSBoaWdoIHNlcXVlbmNlIG51bWJlciBiaXRzIHdoZW4NCj4gPj4gYSBjb21iaW5lZCBt b2RlIGFsZ29yaXRobSBpcyB1c2VkLg0KPiA+Pg0KPiA+PiBSRkMgNDMwMywgU2VjdGlvbiAyLjIu MS4gc2F5czoNCj4gPj4NCj4gPj4gSWYgYSBjb21iaW5lZCBtb2RlIGFsZ29yaXRobSBpcyBlbXBs b3llZCwgdGhlIGFsZ29yaXRobSBjaG9pY2UNCj4gPj4gZGV0ZXJtaW5lcyB3aGV0aGVyIHRoZSBo aWdoLW9yZGVyIEVTTiBiaXRzIGFyZSB0cmFuc21pdHRlZCBvciBhcmUNCj4gPj4gaW5jbHVkZWQg aW1wbGljaXRseSBpbiB0aGUgY29tcHV0YXRpb24uDQo+ID4NCj4gPiBXZSBkbyBub3QgaGF2ZSBh bnkgYWxnb3JpdGhtcyB0aGF0IHVzZSB0aGF0IGZlYXR1cmUsIGFuZCB3ZSBkbyBub3QNCj4gPiBo YXZlIG9wdGlvbiB0byBuZWdvdGlhdGUgaXQgaW4gSUtFdjIuDQo+ID4NCj4gPiBXZSBjb3VsZCBh ZGQgbmV3IHZhbHVlIGZvciB0cmFuc2Zvcm0gdHlwZSA1IChFeHRlbmRlZCBTZXF1ZW5jZQ0KPiA+ IE51bWJlcnMpIHRvIHNheSB0aGF0IHdlIHVzZSBleHRlbmRlZCBzZXF1ZW5jZSBudW1iZXIsIGFu ZCB0aGF0IHdlDQo+ID4gYWN0dWFsbHkgdHJhbnNtaXQgdGhlIGZ1bGwgZXh0ZW5kZWQgc2VxdWVu Y2UgbnVtYmVyLg0KPiANCj4gVGhhdCB3b3VsZCBhbHJlYWR5IGhlbHAgZm9yIHRoZSBjYXNlLg0K PiANCj4gPj4gV2UgY291bGQganVzdCBnaXZlIG11bHRpY2FzdCB0aGUgc2FtZSBvcHRpb24gaWYg aXQgd2FudHMgdG8gdXNlDQo+ID4+IHJlcGxheSBwcm90ZWN0aW9uLg0KPiA+DQo+ID4gQXMgb3Ro ZXJzIGhhdmUgYWxyZWFkeSBwb2ludGVkIG91dCBlYXJsaWVyLCB3aXRoIG11bHRpY2FzdCB0aGUg dXBwZXINCj4gPiBsYXllciBtdXN0IG1ha2UgY2FyZSBvZiByZXBsYXlzIGFuZCBkcm9wcGVkIHBh Y2tldHMgdGhlbXNlbHZlcyBpbiBhbnkNCj4gPiBjYXNlLCBzbyBkb2luZyB0aGF0IGFsc28gb24g dGhlIElQc2VjIGxldmVsIGRvZXMgbm90IHJlYWxseSBwcm92aWRlDQo+ID4gdGhhdCBtdWNoIG1v cmUgc2VjdXJpdHkuIEkgbWVhbiBpZiB0aGUgbXVsdGljYXN0IHByb3RvY29sIHJ1biBvdmVyIFVE UA0KPiA+IG92ZXIgSVBzZWMgc2ltcGx5IGhhcyBpbnRlcm5hbCBzZXF1ZW5jZSBudW1iZXIgaW5z aWRlIHRoZSBVRFAsIHdoaWNoDQo+ID4gd2lsbCB0aGVuIGJlIGF1dGhlbnRpY2F0ZWQgYnkgdGhl IElQc2VjIHRoYXQgc2hvdWxkIGJlIGdvb2QgZW5vdWdoIGZvcg0KPiA+IHJlcGxheSBwcm90ZWN0 aW9uLg0KPiA+DQo+ID4gVGhlcmUgaXMgaXNzdWUgdGhhdCBpbiB0aGF0IGNhc2UgYXR0YWNrZXIg Y291bGQgZG8gRGVuaWFsIG9mIFNlcnZpY2UNCj4gPiBhdHRhY2sgYWdhaW5zdCB0aGUgSVBzZWMs IGJ5IHJlcGxheWluZyBwYWNrZXRzLCBhbmQgdGhlbiB0aGUgSVBzZWMNCj4gPiBnYXRld2F5IHdv dWxkIGRlY3J5cHQgYW5kIGZvcndhcmQgdGhlbS4NCj4gDQo+IExpa2UgcG9pbnRlZCBvdXQgaW4g dGhlIGFuc3dlciB0byBWYWxlcnnigJlzIG1haWwuIFRoZXJlIGFyZSBwb3NzaWJseSBtb3JlDQo+ IGlzc3VlcywgYXMgYXR0YWNrZXJzIGFyZSBhYmxlIHRvIGdlbmVyYXRlIG5ldyB0cmFmZmljLCB0 aGV5IGNhbiB1c2UgZm9yDQo+IGNyeXB0YW5hbHlzaXMgKHNlZSBodHRwczovL3d3dy5haXJjcmFj ay1uZy5vcmcvZG9rdS5waHA/aWQ9YXJwLQ0KPiByZXF1ZXN0X3JlaW5qZWN0aW9uKS4NCj4gSGF2 aW5nIGFudGktcmVwbGF5IGd1YXJhbnRlZXMgaXMganVzdCBhIHJlbGlhYmxlIGZvdW5kYXRpb24u IElNSE8gdGhlIGNhc2Ugb2YNCj4gYXBwbGljYXRpb25zIGJlaW5nIHJlc3BvbnNpYmxlIGhvbGRz IGp1c3QgYXMgd2VsbCBmb3IgdW5pY2FzdCBhcHBsaWNhdGlvbnMuIFRDUA0KPiB0YWtlcyBjYXJl IG9mIHRoYXQsIHN0aWxsIG5vLW9uZSBob25lc3RseSBkaXNjdXNzZXMgcmVtb3ZpbmcgcmVwbGF5 IGNoZWNrcyBmb3INCj4gaGlnaCB2b2x1bWUgdW5pY2FzdCBTQXMuDQo+IA0KPiA+IFdoZW4gdXNp bmcgbXVsdGljYXN0IHlvdSBhbHJlYWR5IG5lZWQgdG8gdXNlIFNQSSwgYW5kIGRlc3RpbmF0aW9u DQo+ID4gYWRkcmVzcyBhcyB5b3VyIFNBRCBsb29rdXAgKFJGQzQzMDMsIHNlY3Rpb24gMi4xKSwg aS5lLiB1c2Ugb3B0aW9uIDINCj4gPiB0aGVyZS4gT24gdGhlIG90aGVyIGhhbmQgeW91IGNvdWxk IHVzZSB0aGUgU1BJLCBkZXN0aW5hdGlvbiBhZGRyZXNzLA0KPiA+IGFuZCBzb3VyY2UgYWRkcmVz cyB0byBmaW5kIHRoZSByZXBsYXkgd2luZG93IGFuZCBsYXJnZXN0IHNlcXVlbmNlDQo+ID4gbnVt YmVyIHVzZWQgaWYgeW91IHdhbnQgdG8gZG8gYW50aS1yZXBsYXkgcHJvdGVjdGlvbiBvbiBtdWx0 aWNhc3QgU0FzDQo+ID4gc28gdGhhdCBlYWNoIHNlbmRlciBoYXMgc2VwYXJhdGUgcmVwbGF5IHdp bmRvd3MuDQo+IA0KPiBUaGlzIHN0aWxsIHJlcXVpcmVzIHRvIGtub3cgYWxsIHBvc3NpYmxlIHNl bmRlcnMgYmVmb3JlaGFuZC4gQWxzbyB0aGUgU0FzIHdpbGwNCj4gc3RpbGwgbmVlZCB0byBhZ3Jl ZSBvbiBhbiBJViBzdWJzcGFjZSBhbmQgc2VuZGluZyBhbiBleHBsaWNpdCBJViBwZXIgcGFja2V0 Lg0KPiANCj4gPj4+IEFuZCBhYm91dCBzZWN1cml0eS4gSW4gb3JkZXIgdG8gaGF2ZSBJViBjb21i aW5lZCB3aXRoIEVTTiBhbmQNCj4gPj4+IHN1Yi13aW5kb3dzIGlkZW50aWZpZXJzIHRoaXMgcHJv cG9zYWwgcmVtb3ZlcyBzZWNyZXQgc2FsdCBmcm9tIHRoZQ0KPiA+Pj4gbm9uY2UuIFRoaXMgbWF5 IGhhdmUgaW1wYWN0IG9uIHNlY3VyaXR5Lg0KPiA+Pj4gSSdtIG5vdCBhIGNyeXB0b2dyYXBoZXIs IGJ1dCBJIGJlbGlldmUgdGhlIGltcGFjdCBpcyBub3QgbmVnbGlnaWJsZS4NCj4gPj4+IE9uIHRo ZSBsYXN0IENGUkcgc2Vzc2lvbiBhIGRyYWZ0IGRyYWZ0LXdvb2QtY2ZyZy1hZWFkLWxpbWl0cyB3 YXMNCj4gPj4+IGRpc2N1c3NlZCB0aGF0IGNhbGN1bGF0ZXMgbGltaXRzIG9mIGRhdGEgdG8gYmUg c2FmZWx5IGVuY3J5cHRlZCBieQ0KPiA+Pj4gdmFyaW91cyBBRUFEIGNpcGhlcnMuIFRoZSBhdXRo b3JzIGNsYWltZWQgdGhhdCBoYXZpbmcgc2VjcmV0IHNhbHQgaW4NCj4gPj4+IHRoZSBub25jZSBp bmNyZWFzZXMgdGhpcyBsaW1pdHMgaW4gY2FzZSBvZiBtdWx0aS11c2VyIGF0dGFja3MgYW5kDQo+ ID4+PiB0aGF0IHRoZSByZXN1bHRzIGluIHRoZSBkcmFmdCBhcmUgY2FsY3VsYXRlZCBmb3IgdGhp cyBjYXNlLiBJZiBwbGFpbg0KPiA+Pj4gQUVBRCBjaXBoZXJzICh3aXRoIG5vIHNlY3JldCBzYWx0 KSBhcmUgdXNlZCB0aGUgbGltaXRzIGFyZSBsb3dlci4NCj4gPj4NCj4gPj4gQSBzZWNyZXQgc2Fs dCBpbiB0aGUgbm9uY2Ugd291bGQgYmUgYSBuZXcgcmVxdWlyZW1lbnQgYW55d2F5Lg0KPiA+PiBJ J3ZlIGNoZWNrZWQgUkZDIDQxMDYgKEVTUCBmb3IgR0NNKSBhbmQgUkZDIDc2MzQgKEVTUCBmb3IN Cj4gPj4gQ2hhQ2hhMjAtUG9seTEzMDUpLCBib3RoIGRvbid0IHJlcXVpcmUgYSBzZWNyZXQgc2Fs dC4NCj4gPg0KPiA+IEl0IGlzIHRydWUgdGhhdCB0aGV5IGRvIG5vdCBuZWVkIHNlY3JldCBzYWx0 LCBidXQgdGhleSBkbyBoYXZlDQo+ID4gdW5wcmVkaWN0YWJsZSBzYWx0LCB3aGljaCBpcyBjcmVh dGVkIGJ5IHRoZSBrZXkgZGVyaXZhdGlvbiBzdGVwLiBNeQ0KPiA+IHVuZGVyc3RhbmRpbmcgd2Fz IHRoYXQgdGhpcyBwcm9wb3NhbCBkaWQgZ2V0IHJpZCBvZiB0aGF0IHNhbHQgdG9vOg0KPiANCj4g TGlrZSB3cml0dGVuIGFscmVhZHk6IEFuIHVucHJlZGljdGFibGUgdmFsdWUgb2YgMzJiaXQgc2l6 ZSBpcyBvZiBubyByZWFsIHZhbHVlDQo+IGZyb20gYSBjcnlwdG8gcG9pbnQgb2Ygdmlldy4gT25l IGNvdWxkIHNpbXBseSBndWVzcyB0aGUgdmFsdWUgYW5kIGhhdmUgYQ0KPiByZWFsaXN0aWMgY2hh bmNlIG9mIGJlaW5nIHJpZ2h0IGFmdGVyIGEgY291cGxlIG9mIHRob3VzYW5kIHRyaWVzLiANCg0K QWN0dWFsbHksIGl0IGRvZXMgYWRkIHZhbHVlIGZyb20gYSBjcnlwdG8gcG9pbnQgb2Ygdmlldywg YXQgbGVhc3QgZnJvbSBhIHNwZWNpZmljIGF0dGFjay4gIEluIGEgbXVsdGl0YXJnZXQgYXR0YWNr LCB0aGF0IGlzLCBhbiBhdHRhY2sgd2hlcmUgd2UgYXNzdW1lIHRoYXQgdGhlIGF0dGFja2VyIGhh cyBlbmNyeXB0ZWQgcGFja2V0cyBmcm9tIGEgbGFyZ2UgbnVtYmVyIG9mIFNBcywgYW5kIGhpcyBn b2FsIGlzIHRvIHJlY292ZXIgdGhlIGtleXMgZm9yIGFueSBvbmUgb2YgdGhlIGVuY3J5cHRlZCBw YWNrZXRzLCBoZXJlIGlzIHdoYXQgdGhlIGF0dGFja2VyIGNhbiBkbyAoYXNzdW1pbmcgR0NNIG9y IENoYUNoYTIwLVBvbHkxMzA1KTsgaWYgaGUgaGFzIHBhY2tldCBlbmNyeXB0ZWQgd2l0aCBlYWNo IFNBIHdpdGggdGhlIHNhbWUgbm9uY2UsIGhlIGNhbiBndWVzcyBhIGtleSwgYW5kIGdlbmVyYXRl IHRoZSBpbnRlcm5hbCBHQ00vQ2hhQ2hhMjAga2V5c3RyZWFtIGJhc2VkIG9uIHRoYXQga2V5L25v bmNlIGNvbWJpbmF0aW9uLiAgSGUgY2FuIHRoZW4gc2NhbiB0aHJvdWdoIGFsbCB0aGUgcGFja2V0 cyB0byBzZWUgaWYgdGhlIGVuY3J5cHRpb24gbWFrZXMgc2Vuc2UgKG9yIHRoZSBJQ1YgdGFnIHdv cmtzIG91dCk7IHRoaXMgY2FuIGJlIGRvbmUgZmFyIGZhc3RlciB0aGFuIGNoZWNraW5nIGVhY2gg cGFja2V0IGluZGl2aWR1YWxseS4gIEFzc3VtaW5nIHRoZSBwYWNrZXRzIGFyZSBlbmNyeXB0ZWQg d2l0aCBBRVMtMTI4LCBhbmQgdGhlIGF0dGFja2VyIGhhcyBwYWNrZXRzIGZyb20gMioqTCBTQXMs IHRoZW4gYWdhaW5zdCB0aGlzIGF0dGFjaywgd2UgaGF2ZSBvbmx5IDEyOC1MIGJpdHMgb2Ygc2Vj dXJpdHkuDQoNCkJ5IGluY2x1ZGluZyAzMiBiaXRzIG9mIHVucHJlZGljdGFibGUgdmFsdWVzLCB3 ZSBtYWtlIHRoaXMgYXR0YWNrIDQgYmlsbGlvbiB0aW1lcyBoYXJkZXIsIGFuZCBmb3IgQUVTLTEy OCwgdGhhdCB3b3VsZCBnaXZlIHVzIDE2MC1MIGJpdHMgb2Ygc2VjdXJpdHkuIFRoaXMgZG9lc24n dCBhY3R1YWxseSBhZGQgYW55IHNlY3VyaXR5IGFnYWluc3QgYXR0YWNrcyBhZ2FpbnN0IGEgc2lu Z2xlIFNBLCBhbmQgdGhlIHNhbHQgZG9lc24ndCBhY3R1YWxseSBuZWVkIHRvIGJlIHNlY3JldC4N Cg0KPiBJIGJlbGlldmUgaXQgaXMNCj4gb25seSBpbiB0aGUgc3RhbmRhcmQsIGFzIHdpdGggNjQg Yml0IHNlcXVlbmNlIG51bWJlcnMgdGhlcmUgd2hlcmUgMzIgYml0cw0KPiBsZWZ0OyBuZWVkaW5n IHRvIGJlIGZpbGxlZC4NCg0KTm9wZTsgaXQgd2FzIGluY2x1ZGVkIHRvIGluY3JlYXNlIHNlY3Vy aXR5LiAgRm9yIDI1NiBiaXQga2V5cywgb25lIGNhbiBlYXNpbHkgYXJndWUgdGhhdCB0aGlzIGlz IG5vdCBuZWVkZWQ7IGhvd2V2ZXIgZm9yIDEyOCBiaXQga2V5cywgaXQgaXMgY29uc2lkZXJhYmx5 IG1vcmUgbWFyZ2luYWwuDQo= From nobody Wed Jul 29 11:30:10 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A02173A0C5D for ; Wed, 29 Jul 2020 11:30:05 -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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugdVsCDkbx-E for ; Wed, 29 Jul 2020 11:30:00 -0700 (PDT) Received: from meesny.iki.fi (meesny.iki.fi [195.140.195.201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 251C13A0AA7 for ; Wed, 29 Jul 2020 11:29:59 -0700 (PDT) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: kivinen) by meesny.iki.fi (Postfix) with ESMTPSA id 927C32008C; Wed, 29 Jul 2020 21:29:57 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1596047397; 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=PUmt+gqrIBa+XBeQq6xaXbBXboRngY/Ao2aWS0Lz3F8=; b=kJIhb0gDjvbY339RHI/HpuCAsQKKjZkQ9Rh5/phEYGVeu1e1TqReEYApokueAoqhrhSFEL Jyf9npDMSJIDoEAreiiJNWCNd9Fk3qxqvraD3DNu4N+wLxbvKgpEIPgFEKR1FxjOd3rHpE FGxv3nqQ+2IGHuiWB2t4agBKoZu44Tw= Received: by fireball.acr.fi (Postfix, from userid 15204) id 37C3E25C136C; Wed, 29 Jul 2020 21:29:57 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <24353.49189.175868.584478@fireball.acr.fi> Date: Wed, 29 Jul 2020 21:29:57 +0300 From: Tero Kivinen To: Michael Rossberg Cc: Steffen Klassert , Valery Smyslov , ipsec@ietf.org In-Reply-To: References: <023E45E1-B1AA-4042-A8E3-DD7457235BC7@tu-ilmenau.de> <0fd501d664b6$fcc8c590$f65a50b0$@gmail.com> <20200729100457.GD20687@gauss3.secunet.de> <24353.30727.115426.454334@fireball.acr.fi> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 20 min X-Total-Time: 63 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1596047397; 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=PUmt+gqrIBa+XBeQq6xaXbBXboRngY/Ao2aWS0Lz3F8=; b=wYaFxd+7SoXLIMD0UZmvEU2z5QkcfnHm1uQW34VjjdsDSUgYvenRAhPUxiAoYJZopO8ztD 4nRjNGcie3q9kfgWJR34qmTxTegGcwG9qJOPhTMjVk6os/YfEdVo4zbEz0nGhHNJ42Qslg l6GuYqEx4GBH0h+AHclerPVm/rWKj08= ARC-Seal: i=1; s=meesny; d=iki.fi; t=1596047397; a=rsa-sha256; cv=none; b=k+nDfKSMta6klgJfQA2lk+dtJdsCqYwDDFrgGTA8CjoKnPtUl2TS0GPlu0E9g8CGHDAwci DgUdtWJn2gDIzIWIPIXYiegSkAzVwgg0TaCqdvsvucx7aV88zn/QsVoLwyoN3rFf42D4xu xooNdNkv7SmB5y9SGHVLckEVvT3IfEE= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [IPsec] Teaser for pitch talk at IETF 108 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, 29 Jul 2020 18:30:07 -0000 Michael Rossberg writes: > Like pointed out in the answer to Valery=E2=80=99s mail. There are po= ssibly more > issues, as attackers are able to generate new traffic, they can use f= or > cryptanalysis (see > https://www.aircrack-ng.org/doku.php=3Fid=3Darp-request=5Freinjection= ). If any of our algorithms are vulnerable to that kind of attacks, we immediately need to move that algorithm to MUST NOT category. None of the modern ciphers should be affected by that.=20 > Having anti-replay guarantees is just a reliable foundation. IMHO the= > case of applications being responsible holds just as well for unicast= > applications. TCP takes care of that, still no-one honestly discusses= > removing replay checks for high volume unicast SAs. Actually there are several complains that people are disabling anti-replay for VPNs just as there are buggy implementations of it, and if you disable it then at least some connections might be more stable... The thing is that you never know whether it is disabled on the receiver or not... > > When using multicast you already need to use SPI, and destination > > address as your SAD lookup (RFC4303, section 2.1), i.e. use option = 2 > > there. On the other hand you could use the SPI, destination address= , > > and source address to find the replay window and largest sequence > > number used if you want to do anti-replay protection on multicast S= As > > so that each sender has separate replay windows. >=20 > This still requires to know all possible senders beforehand. Also the= > SAs will still need to agree on an IV subspace and sending an explici= t > IV per packet. Yes, this is similar than your proposal, except it uses standard ESP. I.e., you need to know which sender IDs are to be used, here you need to know which source addresses are used. You also need to transmit Sender ID inplace, in standard ESP you reserve part of IV for that purpose and use that. Note, that if you use SPI, destination address and source address to find the replay protection information you do not need to transmit that part of IV inplace. I.e. the SAD has the 32-bit salt for GCM Nonce + the IV from the packet (whether it is actual transmitted IV, or implicit IV in form of sequence number does not matter). You could simply make multicast SAs in such way that they only have 16-bit random salt per SA, and other 16-bit of the random salt is per sender. This means when multicast SA is created it creates 16-bits of common salt, and then when sender joins the group, it will get unique 16-bits random salt assigned to it. This 16-bit salt part + sequence number + replay window is stored to the list of senders indexed by sender address under the SA. There are most likely also other ways of doing the same thing. Good thing is that we already have the g-ikev2 doing group key management using IKEv2, so we can easily make sure we can do needed negotiations in there. All multicast traffic cases are going to be needing that g-ikev2 anyways, so my proposal is that we move discussion about multicast cases to that g-ikev2 discussion.=20 > Like written already: An unpredictable value of 32bit size is of no > real value from a crypto point of view. One could simply guess the > value and have a realistic chance of being right after a couple of > thousand tries. I believe it is only in the standard, as with 64 bit > sequence numbers there where 32 bits left; needing to be filled. I think it came from the NIST documents where it was called fixed field. The idea was to make sure that even if someone accidently used same key twice for two different SAs, this will not cause issues, as that fixed field is going to be unique anyways. I.e. NIST 800-38D section 8.2.1 says: ---------------------------------------------------------------------- ... The lengths and positions of the fixed field and the invocation field shall be fixed for each supported IV length for the life of the key. In order to promote interoperability for the default IV length of 96 bits, this Recommendation suggests, but does not require, that the leading (i.e., leftmost) 32 bits of the IV hold the fixed field; and that the trailing (i.e., rightmost) 64 bits hold the invocation field. --=20 kivinen@iki.fi From nobody Wed Jul 29 11:35:27 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA973A0E3A for ; Wed, 29 Jul 2020 11:35:17 -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 ncg4RAZnum89 for ; Wed, 29 Jul 2020 11:35:14 -0700 (PDT) Received: from smail.rz.tu-ilmenau.de (smail.rz.tu-ilmenau.de [141.24.186.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B6113A0E3C for ; Wed, 29 Jul 2020 11:35:14 -0700 (PDT) Received: from [192.168.2.166] (unknown [93.253.126.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smail.rz.tu-ilmenau.de (Postfix) with ESMTPSA id 2315A580060; Wed, 29 Jul 2020 20:35:11 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_B87FF154-B379-4B17-AD39-BE213145E212"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Michael Rossberg In-Reply-To: Date: Wed, 29 Jul 2020 20:35:10 +0200 Cc: ipsecme mailing list Message-Id: <25B2E4EE-6A2B-4324-B16C-DFCB54AC9E87@tu-ilmenau.de> References: <023E45E1-B1AA-4042-A8E3-DD7457235BC7@tu-ilmenau.de> <0fd501d664b6$fcc8c590$f65a50b0$@gmail.com> <20200729100457.GD20687@gauss3.secunet.de> <24353.30727.115426.454334@fireball.acr.fi> To: "Scott Fluhrer (sfluhrer)" X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [IPsec] Teaser for pitch talk at IETF 108 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, 29 Jul 2020 18:35:25 -0000 --Apple-Mail=_B87FF154-B379-4B17-AD39-BE213145E212 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >=20 > Actually, it does add value from a crypto point of view, at least from = a specific attack. In a multitarget attack, that is, an attack where we = assume that the attacker has encrypted packets from a large number of = SAs, and his goal is to recover the keys for any one of the encrypted = packets, here is what the attacker can do (assuming GCM or = ChaCha20-Poly1305); if he has packet encrypted with each SA with the = same nonce, he can guess a key, and generate the internal GCM/ChaCha20 = keystream based on that key/nonce combination. He can then scan through = all the packets to see if the encryption makes sense (or the ICV tag = works out); this can be done far faster than checking each packet = individually. Assuming the packets are encrypted with AES-128, and the = attacker has packets from 2**L SAs, then against this attack, we have = only 128-L bits of security. >=20 > By including 32 bits of unpredictable values, we make this attack 4 = billion times harder, and for AES-128, that would give us 160-L bits of = security. This doesn't actually add any security against attacks against = a single SA, and the salt doesn't actually need to be secret. Thanks for clarification. I guess I have been thinking too SA centric. In fact we always discussed AES-256 only. Do you agree that starting the window/sender IDs with random offsets = would fix this weakness? --Apple-Mail=_B87FF154-B379-4B17-AD39-BE213145E212 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEE/ZtCXI3ladZ37VLCzADDFAM3dskFAl8hwV4ACgkQzADDFAM3 dsnc7g/9FVJ4r99xdXE8fqeIkv2eKnX6/VRUZFg4+pX4mBn00U5uT9+1XHMnmxlq //eIBlZHO5Hcnp7nXoEVWtMHBOV+Ig2UC6giCb8aMpw6nD3fjz0orrFtVOWJ8BSh JRB0VPB44Qrn8yqmP2ifOOK6lyWX+A9xzTkxQ/wLCh3Ci9O4Apj12TyxCnhN1ybY ZIVVRk/0NbEqUvM7ZK+FO2aUpF7zFT1ctEaf58Ln0NJQtL2rFZlVveltkWTY1an7 wWHAeuabO1X4HLyBg8F09jaq65NW1az/L3phPAgBZt/0a/UTzaVkZvmjcuR2nh4a 5CfC3Z26rU/5KrDqsPAcNDx4FOAoSG1XOfh9dlIxcyPWBskGfBfPjgfL2hDPbCsH gs/rIAiJuM/h+JPph0Ps+tObfYXpqEgurWB0+sZOClGCSewWLk6dX/UgPeiFKvYM CnA4p+votA3VaxsOrcVnjePnwJoW9vlD4EvOvS6StPOEPJ7Qmdz3YQizWhO66O9U K+hLEjXsjdjW6eGFvmsmOlahwXoR6dqDMCpfl4pSZN8mMzhyCUh5q9IfARTJYOyS W3toxv5IN7sQlSE3VPxvvokHtB/RW9NtweDzF/S4XooDCTqBV3mE2PFnqrJWvoaU qArj1cA9WG7SEAH3AxqUdvLAjJGbXJoYxVBSAVmaRL4aTMMkrXo= =Puo7 -----END PGP SIGNATURE----- --Apple-Mail=_B87FF154-B379-4B17-AD39-BE213145E212-- From nobody Wed Jul 29 11:52:43 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0423A0E30 for ; Wed, 29 Jul 2020 11:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=TQz+NlMu; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=TJnoU+Xr 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 6k-lUdapMCPO for ; Wed, 29 Jul 2020 11:52:37 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FFF43A0E2D for ; Wed, 29 Jul 2020 11:52:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1492; q=dns/txt; s=iport; t=1596048757; x=1597258357; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8QrMeh1+BkeSi31IBMuxjiuPkcvWUaJpH4Xhnjr51uo=; b=TQz+NlMujfZnQgolehs2BCUtaUXSz+GMYnB1H+eiQC3DrDchq6f/mcLf D6Y1heplQ5ObopYWxdu0C/zqtETH/xqrulvh8gDxEW1mJFLKrZELpb7Rf v+LbIqXz3xGHZmaB71GDGyo9XRmBgDKOYv8eWSCon3Kc9tQVvnLVu/sr3 Q=; IronPort-PHdr: =?us-ascii?q?9a23=3AQf/lpRAPj8Dle4VA+u0bUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qw13A3IXoSd5fMXw+bVsqW1X2sG7N7BtX0Za5VDWl?= =?us-ascii?q?cDjtlehA0vBsOJSCiZZP7nZiA3BoJOAVli+XzoMEtUXsj/NBXep3So5msUHR?= =?us-ascii?q?PyfQN+OuXyHNvUiMK6n+C/8pHeeUNGnj24NLhzNx6x6w7Ws5ob?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DrAQBQxCFf/5ldJa1gGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAUCBSoFSUQeBRy8sCoQrg0YDjU+YYYJTA1ULAQEBDAE?= =?us-ascii?q?BLQIEAQGETAIXgg0CJDgTAgMBAQsBAQUBAQECAQYEbYVcDIVxAQEBBBIREQw?= =?us-ascii?q?BATcBCwQCAQgVAQQCJgICAjAVEAIEAQ0FCBqFUAMuAaR3AoE5iGF2gTKDAQE?= =?us-ascii?q?BBYUPGIIOCYEOKgGCboNfhHyBQxqBQT+BEUOCHy4+gQSDO4MUM4ItkjM9oxg?= =?us-ascii?q?Kgl+aIJ90kiCfHwIEAgQFAg4BAQWBaiOBV3AVgyRQFwINjh4MF4NOilZ0NwI?= =?us-ascii?q?GCAEBAwl8jlQBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.75,411,1589241600"; d="scan'208";a="795875069" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Jul 2020 18:52:35 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 06TIqZEo025218 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Jul 2020 18:52:35 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 29 Jul 2020 13:52:34 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 29 Jul 2020 13:52:34 -0500 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 29 Jul 2020 13:52:34 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Wh0ebcijWlFFN7bbWUaf/h3ajvZB/zSQJyTFj5ir3viKPspGkxzpbaOj4ciylWko+Z1LFvkzVXS2CowfhTulC20dl85fUqadwXZKSg3LkllVq4tdB7lxUpUN90U7oGa5T1LfRBZldygEXSUW0T0poogUVWaU9PFa/9jbHRGJUnxfS7Ha6HgRviPStqUkHp+vyZlQVuwER2rWPRe3pfC622yDJEDykPJp/nmcobTB1kV3tE1NCyXes1dXTDfj9RfgyruvyntAmt+1RlAaUQ3Wgoegn8MVprwBw3SaM4ljy+awWRsOIydJmSEOr+sk9V8czsAVD1PjAB4h6It4Hyk8fA== 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=8QrMeh1+BkeSi31IBMuxjiuPkcvWUaJpH4Xhnjr51uo=; b=ksGecb4JEyiqIlgkkMb7bxEdgv3Y2WWOdmKeLi843L2c/ednkSvZ3TiYmdyq6BGcdZ1t3ViZYvbiQBha+MyFpsb0pRd9zT8ot3kBEWlp1ZQma36Jx1+yXge5kFmgmGycJZLD27JlQyRu/DOVIeTopz9/CVhMsemxQIAkdI72MenbSKodSvblkgEjZQEi71/AFPOGSkftQgyFyH+ZVvVog3Ryh5clIDKhI5Vvz0JL0sL3OkyekeyI/lqFgqb0mXE82NgWlDervqc/NNPguHb++0+Etphmx/dQQXsrktr623ReD8UlyRN6L33cFEAotYkoTYhv3WOvLx/Va6P2Zalzdg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8QrMeh1+BkeSi31IBMuxjiuPkcvWUaJpH4Xhnjr51uo=; b=TJnoU+Xr/LiS+Vzc285ghg/x9UOdGroCJIpxmJBu3LNzznitL4lfmvcDHSM03VhbWYSRgTeBBhhjCITRHfES41m64Ovoal4BXs6ZJLszONC0FAlSlGuLM0DQ63XVQkDGfTZNli8G3aB8n6gkyZmeWVcWvdF6hcUoaKsRRjp6Mv8= Received: from BN7PR11MB2641.namprd11.prod.outlook.com (2603:10b6:406:b1::25) by BN6PR11MB1396.namprd11.prod.outlook.com (2603:10b6:404:4a::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.22; Wed, 29 Jul 2020 18:52:33 +0000 Received: from BN7PR11MB2641.namprd11.prod.outlook.com ([fe80::5018:edeb:b77d:4d65]) by BN7PR11MB2641.namprd11.prod.outlook.com ([fe80::5018:edeb:b77d:4d65%3]) with mapi id 15.20.3216.034; Wed, 29 Jul 2020 18:52:33 +0000 From: "Scott Fluhrer (sfluhrer)" To: Tero Kivinen , Michael Rossberg CC: Steffen Klassert , "ipsec@ietf.org" , Valery Smyslov Thread-Topic: [IPsec] Teaser for pitch talk at IETF 108 Thread-Index: AQHWYBKzgiV8IDTYWUmmokuEibQdmKkcrdKAgAGxdYCAADcggIAALvYAgAAnAoCAAAV74A== Date: Wed, 29 Jul 2020 18:52:32 +0000 Message-ID: References: <023E45E1-B1AA-4042-A8E3-DD7457235BC7@tu-ilmenau.de> <0fd501d664b6$fcc8c590$f65a50b0$@gmail.com> <20200729100457.GD20687@gauss3.secunet.de> <24353.30727.115426.454334@fireball.acr.fi> <24353.49189.175868.584478@fireball.acr.fi> In-Reply-To: <24353.49189.175868.584478@fireball.acr.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: iki.fi; dkim=none (message not signed) header.d=none;iki.fi; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e005ccd8-3a4f-4299-7508-08d833f08daa x-ms-traffictypediagnostic: BN6PR11MB1396: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kZ9gZ60MaDfJZKYbwlkioP5CRxiGVIRlHfoCfr1vyVSbDewveAUVJ0qgqRhCrSRiXMN5Jcw7+22b3YNUFreBdAedSUsgatT8a4McGnAVHkOUX+L+fjU7mIRi0fQ/pfcpyhHsAPB3fcNfW5EXpspBTR10Pl7VFSAjxtSq/9DtbG15RlpxuneR+eCr3S5g2PXRwdO8/NaIs56I3tRldS5S5DFGQyM941UkOvkWQEFmE16NAFCGEQb2+EEm1hIo9KD8cVuFVHcAI9THxhHhG6nUe8M7ldnDPtTFibjKo+C9cWXGV796REEonslxLzufYBYCmGwItBMQ9TIlKl8sqYbPBg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2641.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(39860400002)(366004)(346002)(136003)(376002)(83380400001)(2906002)(7696005)(6506007)(53546011)(55016002)(478600001)(33656002)(110136005)(316002)(52536014)(76116006)(54906003)(9686003)(8676002)(5660300002)(86362001)(71200400001)(66476007)(66556008)(186003)(66946007)(66446008)(4326008)(8936002)(4744005)(64756008)(26005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: pzKYafYwjZQZBtHVS+L9laeB+T4dBxuoE1iffUfgBSONhEWD3V6iZQxhs3k9NeVA9Q6/8f8mAjRfVriz+/sX7tUFN3EQzR8Si3iF8NLZ2d/8Z0Ex2NbLKq4hq1Susq+G5Pt0tgHTmdUCQzYdh3PQJxKS0jls6SYOKevDA+L6mPKsEwOtr6+f9+I37Jhw6y+VATRPJLJ23XIjwWGetgtTlefjeZmcNBustUessO4X9R1VzVNSrXWSv5lmkOwpcmQewG4bJk+JMyIpZr5yR+u53003Z/dZ6bU7z9kvCj5bm8/iBS9khcG/6lc+0DXGaiLuWsIfjdmpxivtzxrKYowdRJNbd7AuEWS+FXVv+2GwHeAWqqgVG4urbBENeD2seZIddYweS6r6dRqMrQdgmAkEe19GUGRpTsZIUSSP1NnOWQ25WLbhvuO/ixmk8yJNFSgXevUgouJPo8W4T6n1dg/gbB/EccCC4Xp+ggBlqTERK8E= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN7PR11MB2641.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e005ccd8-3a4f-4299-7508-08d833f08daa X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jul 2020 18:52:33.2342 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Un88hamaV/O2r93knNdy83ojQncaeYI5krb6q0coK+qfB84LxCa81Ttgg6Z+y/wC9wQtiCVKDfSyKNCt3gpQrA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1396 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [IPsec] Teaser for pitch talk at IETF 108 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, 29 Jul 2020 18:52:41 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBJUHNlYyA8aXBzZWMtYm91bmNl c0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIFRlcm8gS2l2aW5lbg0KPiBTZW50OiBXZWRuZXNkYXks IEp1bHkgMjksIDIwMjAgMjozMCBQTQ0KPiBUbzogTWljaGFlbCBSb3NzYmVyZyA8bWljaGFlbC5y b3NzYmVyZ0B0dS1pbG1lbmF1LmRlPg0KPiBDYzogU3RlZmZlbiBLbGFzc2VydCA8c3RlZmZlbi5r bGFzc2VydEBzZWN1bmV0LmNvbT47IGlwc2VjQGlldGYub3JnOyBWYWxlcnkNCj4gDQo+ID4gTGlr ZSB3cml0dGVuIGFscmVhZHk6IEFuIHVucHJlZGljdGFibGUgdmFsdWUgb2YgMzJiaXQgc2l6ZSBp cyBvZiBubw0KPiA+IHJlYWwgdmFsdWUgZnJvbSBhIGNyeXB0byBwb2ludCBvZiB2aWV3LiBPbmUg Y291bGQgc2ltcGx5IGd1ZXNzIHRoZQ0KPiA+IHZhbHVlIGFuZCBoYXZlIGEgcmVhbGlzdGljIGNo YW5jZSBvZiBiZWluZyByaWdodCBhZnRlciBhIGNvdXBsZSBvZg0KPiA+IHRob3VzYW5kIHRyaWVz LiBJIGJlbGlldmUgaXQgaXMgb25seSBpbiB0aGUgc3RhbmRhcmQsIGFzIHdpdGggNjQgYml0DQo+ ID4gc2VxdWVuY2UgbnVtYmVycyB0aGVyZSB3aGVyZSAzMiBiaXRzIGxlZnQ7IG5lZWRpbmcgdG8g YmUgZmlsbGVkLg0KPiANCj4gSSB0aGluayBpdCBjYW1lIGZyb20gdGhlIE5JU1QgZG9jdW1lbnRz IHdoZXJlIGl0IHdhcyBjYWxsZWQgZml4ZWQgZmllbGQuIFRoZQ0KPiBpZGVhIHdhcyB0byBtYWtl IHN1cmUgdGhhdCBldmVuIGlmIHNvbWVvbmUgYWNjaWRlbnRseSB1c2VkIHNhbWUga2V5IHR3aWNl DQo+IGZvciB0d28gZGlmZmVyZW50IFNBcywgdGhpcyB3aWxsIG5vdCBjYXVzZSBpc3N1ZXMsIGFz IHRoYXQgZml4ZWQgZmllbGQgaXMgZ29pbmcgdG8NCj4gYmUgdW5pcXVlIGFueXdheXMuDQoNCk5v LCBSRkM0MTA2IChKdW5lIDIwMDUpIHByZWRhdGVkIDgwMC0zOEQgKE5vdmVtYmVyIDIwMDcpIGJ5 IG92ZXIgdHdvIHllYXJzLg0KDQpJbnN0ZWFkLCBpdCB3YXMgaW5zZXJ0ZWQgdG8gaGFyZGVuIHRo ZSBzeXN0ZW0gYWdhaW5zdCBtdWx0aXRhcmdldCBhdHRhY2tzLCBhcyBJIHNhaWQgZWFybGllci4u Lg0KDQo= From nobody Wed Jul 29 11:54:26 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6AB3A0E31 for ; Wed, 29 Jul 2020 11:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=dl+81COS; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=JVuFD8j7 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 Ov9MNLwOgR0B for ; Wed, 29 Jul 2020 11:54:22 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E666A3A08AC for ; Wed, 29 Jul 2020 11:54:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1861; q=dns/txt; s=iport; t=1596048861; x=1597258461; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=EhkvflB4IqvgsyActpeuPeVmOtKbRZdA5WOvQvwy2c0=; b=dl+81COSbM0QJYuiK+KRrnVhUmtTmmgFv4t6WUcyOSLwJ+f94MtMCgFQ yIIgJD1DWOy+9Ysocoo2/hk1TfmCb4+ha/g0n/kvq4L7ZYgBt2AG242cf PA2Nyjcly8/8TrfQjgAsyoty8R5BX01K2yVe5RZ/K8uv70JDQ/ZXjAVZ4 o=; IronPort-PHdr: =?us-ascii?q?9a23=3AOOdd3BPro6vG68p+E1Yl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvK833kPUGITf7v9CgveQv62zEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsute0CXo3m34DgbB1?= =?us-ascii?q?PzOFk9KuH8AIWHicOx2qi78IHSZAMdgj27bPtyIRy6oB+XuNMRhN5pK706zV?= =?us-ascii?q?3CpX4bdg=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DCBQAgxSFf/5hdJa1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUqBUlEHgUcvLAqHcQONT5hhglMDVQsBAQEMAQEtAgQBAYR?= =?us-ascii?q?MAoIkAiQ4EwIDAQELAQEFAQEBAgEGBG2FXAyFcQEBAQQSKAYBASwLAQsEAgE?= =?us-ascii?q?IEQQBAR8QMh0IAgQOBQgahVADLgGkfAKBOYhhdIE0gwEBAQWFDhiCDgmBOIJ?= =?us-ascii?q?vh1OBCIEmHRqBQT+BVIIfLj6BBIM7g0eCLbQYgXAKgl+aIJ90sT8CBAIEBQI?= =?us-ascii?q?OAQEFgWojgVdwFTuCaVAXAg2OHoNxilZ0NwIGCAEBAwl8jlQBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.75,411,1589241600"; d="scan'208";a="535152329" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Jul 2020 18:54:20 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 06TIsK4U022858 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Jul 2020 18:54:20 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 29 Jul 2020 13:54:20 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 29 Jul 2020 13:54:20 -0500 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 29 Jul 2020 13:54:20 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iArsnESrVrkFKBQlCaUlnl/iWMkNT7gvuSfeo1/0H42JDdIscgEBzJOEVdt4tACftArbUxOKoYOdo2joULHLLMYHc6/CgPMy4mj4NdcH6bLXpwiwpkIKhMB6OnOeIRPFkvIgsdbgTWfn7DFJs9Ia9t51YFzEpQo+swC3kPI4vLIeE7qF/+hihLU7K3IK+firIpnawJsKWopPCmRV8EPS1217RFpRUUiKCVeaAAIHVVy8IpK3l4Vc+yK0m1dcum45m5eoEVI6ZI4Dj4n6avW4XRUa/MUyPi5s0xvurOIpj11k08K9M1y9YeGo4Icv03jxD5pryfTeLAuOXjhatgc8rw== 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=4J9uOAK4dE2VUTiwa1UVoGFy4jr8fURdSuZueuh4dUs=; b=OAGjSJGfW0M9gA44/wsS314ooR5a5usELSNkPIixgXmoHdQ2g8OMneQK4JnIwNW+yDEKGi/dtMeK+GYbDzCYO1E72DQJRlfzNpovTAe4PZB5RG9wTEWuxfF6TEX3j7BtsNmAmk9MOVeOdX1DMPm2+DyVMS88aSOR0uVeutXTyHge6irGOC+8Y34aIcQXXIg+8IxPt8EXpJFZWsg44ia7dR14QSrbclCRP/Ez4qGxQMEzLws94yegWjD1RyQyvKZl5rSwBkhGiTUQXpCxSG0MsjCEo+joh8mDXZEkej7V/oPvIKLLNfZtB1s8PurV2OWE7oon/kGXEH0qHP6G93vWCg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4J9uOAK4dE2VUTiwa1UVoGFy4jr8fURdSuZueuh4dUs=; b=JVuFD8j7OH+d6ZHTCB1JzBJZdKh89zTUzTJk7cF5Jm0FpXaYgAC3wibkJK8U1fYQRdpBNOO2mBcY3i4XUPkLDMJ0gOU2u4WxUxHXhXQ7hkelA2PyxoRItC1ALvc/Yp8zp3wd9iq7d/DaV4k5Em1uLhRRugzMyz4NdLgs34Lqyjw= Received: from BN7PR11MB2641.namprd11.prod.outlook.com (2603:10b6:406:b1::25) by BN6PR11MB1396.namprd11.prod.outlook.com (2603:10b6:404:4a::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.22; Wed, 29 Jul 2020 18:54:19 +0000 Received: from BN7PR11MB2641.namprd11.prod.outlook.com ([fe80::5018:edeb:b77d:4d65]) by BN7PR11MB2641.namprd11.prod.outlook.com ([fe80::5018:edeb:b77d:4d65%3]) with mapi id 15.20.3216.034; Wed, 29 Jul 2020 18:54:19 +0000 From: "Scott Fluhrer (sfluhrer)" To: Michael Rossberg CC: ipsecme mailing list Thread-Topic: [IPsec] Teaser for pitch talk at IETF 108 Thread-Index: AQHWYBKzgiV8IDTYWUmmokuEibQdmKkcrdKAgAGxdYCAADcggIAALvYAgAAEYRCAACQXAIAABPjw Date: Wed, 29 Jul 2020 18:54:19 +0000 Message-ID: References: <023E45E1-B1AA-4042-A8E3-DD7457235BC7@tu-ilmenau.de> <0fd501d664b6$fcc8c590$f65a50b0$@gmail.com> <20200729100457.GD20687@gauss3.secunet.de> <24353.30727.115426.454334@fireball.acr.fi> <25B2E4EE-6A2B-4324-B16C-DFCB54AC9E87@tu-ilmenau.de> In-Reply-To: <25B2E4EE-6A2B-4324-B16C-DFCB54AC9E87@tu-ilmenau.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tu-ilmenau.de; dkim=none (message not signed) header.d=none;tu-ilmenau.de; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 636753bc-b608-4953-1d94-08d833f0cccb x-ms-traffictypediagnostic: BN6PR11MB1396: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: pBnPUhjqwP2CCFBsz57iPEydw/R+AaSlTHhz9xZ0AnzQyxuZgtF3omUxtz2u+7djSc8GmdLWr3MA/cyS0aSf5QiBx5jh51I5wLq6y7MYqLaYGOquuhndggN8vC17uQ6QnfEPOkpos10Og7ub5ytexdRqKbTSU8xh1ELgGrqQUqhlm9lrnbWxjK7NLmencSgKAw5MhnFrWzZGYhMNesCCs0If97mb3mQNepq5iIb3QBoAMB+WxQKyOhbtvbpLvpZc16kPoWWifyDRD2LqX7d7wgTa+g7a7nflnACQUoip3GfrIo0kwH1ZgoGqz36VzI+jXwN2VEDdNlAPYfSC/2iO0Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2641.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(39860400002)(366004)(346002)(136003)(376002)(83380400001)(2906002)(7696005)(6506007)(53546011)(55016002)(478600001)(33656002)(316002)(52536014)(6916009)(76116006)(9686003)(8676002)(5660300002)(86362001)(71200400001)(66476007)(66556008)(186003)(66946007)(66446008)(4326008)(8936002)(64756008)(26005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: AxDxZlAm3/ZuU5gMntuF2411ag2vV80QONbT4vz8kZ23phy05QKQO/CX21qjbkK5KScbBmoUN5BMvRSdji+G/zILzBJ5X3yzmBaalK6BOSjmt5StiVtyKWLBdSz++QDnV11bwigj+GQoRfeqmsjxlBVq8yDp9YZlquXAPl7Ia2qJ462yftC3SoFZAlFav+zFsV3z9SFsHElGEVe9PK0kqaz4X+g61+RiXpyen0Bmi9OicDUNqffMfWkM7iCRRbAOCm6hv6xFPictvJb38dYTRwW7+0sJrFxQRDhuL4rRq8zSddyUuAOg8F6IQY9UVz8QgNP5xKKtBiTA7hFUer4KgqFZftJ4orB9h6DbX7uiaRmpovgjEyz7Tjqt7QjQ420xv3e6QmE3wdDvxgJhbT6Dkild7Knv9vaw9BVjQuXI8NnPZin3uM44EaGttRXtL+NVtXmg1FLwN2QteHbbzVsu0DEgWrnPyY100rGqkAb/Raw= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN7PR11MB2641.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 636753bc-b608-4953-1d94-08d833f0cccb X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jul 2020 18:54:19.1667 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: IaYTGFWdB/Uo57wbD+3daA9oQHQUesM0/1zYInh4hvX2cggpctIr2CmQ4HDEOyOwthBSLKPCXdRC6MtMpibjiA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1396 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [IPsec] Teaser for pitch talk at IETF 108 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, 29 Jul 2020 18:54:24 -0000 > -----Original Message----- > From: Michael Rossberg > Sent: Wednesday, July 29, 2020 2:35 PM > To: Scott Fluhrer (sfluhrer) > Cc: ipsecme mailing list > Subject: Re: [IPsec] Teaser for pitch talk at IETF 108 >=20 > > > > Actually, it does add value from a crypto point of view, at least from = a > specific attack. In a multitarget attack, that is, an attack where we as= sume > that the attacker has encrypted packets from a large number of SAs, and h= is > goal is to recover the keys for any one of the encrypted packets, here is= what > the attacker can do (assuming GCM or ChaCha20-Poly1305); if he has packet > encrypted with each SA with the same nonce, he can guess a key, and > generate the internal GCM/ChaCha20 keystream based on that key/nonce > combination. He can then scan through all the packets to see if the > encryption makes sense (or the ICV tag works out); this can be done far > faster than checking each packet individually. Assuming the packets are > encrypted with AES-128, and the attacker has packets from 2**L SAs, then > against this attack, we have only 128-L bits of security. > > > > By including 32 bits of unpredictable values, we make this attack 4 bil= lion > times harder, and for AES-128, that would give us 160-L bits of security.= This > doesn't actually add any security against attacks against a single SA, an= d the > salt doesn't actually need to be secret. >=20 > Thanks for clarification. I guess I have been thinking too SA centric. > In fact we always discussed AES-256 only. >=20 > Do you agree that starting the window/sender IDs with random offsets > would fix this weakness? Yes, it would address this weakness. On the other hand, with AES-256, you = don't really need this anyways... From nobody Wed Jul 29 12:19:38 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43233A0E3C for ; Wed, 29 Jul 2020 12:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_MIME_MALF=0.01, 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 5ARUVbaXw-y9 for ; Wed, 29 Jul 2020 12:19:34 -0700 (PDT) Received: from us-smtp-delivery-131.mimecast.com (us-smtp-delivery-131.mimecast.com [216.205.24.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C715A3A0E3B for ; Wed, 29 Jul 2020 12:19:33 -0700 (PDT) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2173.outbound.protection.outlook.com [104.47.55.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-475-0S9EXkTnOeuwsKzv9-X3-w-1; Wed, 29 Jul 2020 15:19:25 -0400 X-MC-Unique: 0S9EXkTnOeuwsKzv9-X3-w-1 Received: from MN2PR08MB6189.namprd08.prod.outlook.com (2603:10b6:208:1b1::19) by BL0PR08MB5297.namprd08.prod.outlook.com (2603:10b6:208:2a::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.17; Wed, 29 Jul 2020 19:19:21 +0000 Received: from MN2PR08MB6189.namprd08.prod.outlook.com ([fe80::40b7:a029:15bc:b092]) by MN2PR08MB6189.namprd08.prod.outlook.com ([fe80::40b7:a029:15bc:b092%8]) with mapi id 15.20.3216.034; Wed, 29 Jul 2020 19:19:21 +0000 From: "Robinson, Herbie" To: "ipsec@ietf.org" Thread-Topic: [EXTERNAL] IPsec Digest, Vol 195, Issue 22 Thread-Index: AQHWZdqh2mbjypVKMUe0gZMntlX4qakeq4+A Date: Wed, 29 Jul 2020 19:19:21 +0000 Message-ID: <03C8658C-D335-4DA7-8272-8AB50C110A4A@stratus.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 x-originating-ip: [108.26.229.129] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: aee160c0-8ca8-48c0-681f-08d833f44c49 x-ms-traffictypediagnostic: BL0PR08MB5297: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: lbzoGPo3ba4zk762TIQvaYJh4gBaWf1Cgq5WvEjixo6XwWaj2G+fvsCdGhgldRy1hkF2lr4K6dIvcXbCh12aq+ZX1274Tn9JovZCJ2sizAz5eymwb/FSW3jrs15STeRAqrS2B71hSlhsLCfeLXkmvZNa3z7mobTe8Chqy1gFRdc6XUMbeJruy9rZfgRSQfQiIeaykJurVYc7mzLoB3nqN0NdgGsJx53WOaLRxgP2huekbqhvlZr4b/Mr4UDjpRqjZx8DIQ5McFYpKBCIqVGgQY04TwmZD5Cojeof3cYVtXk2+kh/QJws8ym8vFK5JqNVnAA0SZn+0Gu3ch3AILvHVcMtA65PAnYW/qfFARga1vu71ohJ/oE8gWssATykxQifECfc9pVR54eJ+6WPFxPiPw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR08MB6189.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(39850400004)(136003)(396003)(366004)(376002)(346002)(2616005)(6916009)(2906002)(86362001)(8936002)(33656002)(186003)(83380400001)(66446008)(5660300002)(66556008)(966005)(45080400002)(36756003)(166002)(478600001)(53546011)(6506007)(64756008)(66476007)(76116006)(66946007)(6512007)(316002)(71200400001)(26005)(6486002)(8676002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: V8NJO7WXMMZDcHMuAQHUgLA1D1A6vbkwjKkX9a/CB1a99m0hcQ9ooqlNyx8l0G6mrDm25k/HdH/luHhSVyEAiLtY8Pg6GLyUlw2/aJiE9K6hqq4c7ZM5qk8scbesE5icoOxB+z7IAHQe+g1niif4rn9Sx3ZItY/ceIestONJ3NzhkLi8Qy1dekQU6OBbUiDyr1LywbatxqFAKfWeF0Ma4Mym8d4ynq+t2u/TzQuraGkQSMK/bL4JbluxotTcgZv9abuMVq/mw/lWcyxukSS3mjYGJj1TW/RjDahSDULJKL+twq2mSFCjbHdx8Zo/khkgsSotOoeGxrMxeLO9bL9DETDsyflb2wT7itlruxsS3hQT10f7aDNbdhy9MdFazBDtlMvO+ytbyoRvfB0XoerbP1pAr5TChhzso+9yOzdbcodGb8oBNqH9OvPHefsVYS3pV1ArcVyEJiZUMiYgr7loDQk5XcPI4lOIIjzu2mc/CgJoQm3gOw0eWt5eEOPQm0ivZC58ehK9o2UcCNC2aOj1xQi3YnVBn3FDDrM9zVxSU8TWqQvyQpNdx0jE+qgMppRr2YvrW9oOCm3DwKhzmBqH8YZnxO7b8j8iVL1NLbX19NjTdE6kh1biwdbjwUzWslrKcbc7C7nUGkkSuR2JRv4EeA== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: stratus.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR08MB6189.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: aee160c0-8ca8-48c0-681f-08d833f44c49 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jul 2020 19:19:21.5859 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: de36b473-b8ad-46ff-837f-9da16b8d1b77 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dyNhoEXi+mIe1RGi9WzBpaDxOuYuPivWhPj56E+t0nMtG95gkQEpDVU1BP+3PQQTYznJ6zydAMTUyWW4gWWWngdJ2PDcp29FWyGR+xUNXsE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR08MB5297 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: stratus.com Content-Type: multipart/alternative; boundary="_000_03C8658CD3354DA782728AB50C110A4Astratuscom_" Archived-At: Subject: Re: [IPsec] [EXTERNAL] IPsec Digest, Vol 195, Issue 22 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, 29 Jul 2020 19:19:37 -0000 --_000_03C8658CD3354DA782728AB50C110A4Astratuscom_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 a2VybmVsL2RvY19jaGFuZ2VzDQoNCkZyb206IElQc2VjIDxpcHNlYy1ib3VuY2VzQGlldGYub3Jn PiBvbiBiZWhhbGYgb2YgImlwc2VjLXJlcXVlc3RAaWV0Zi5vcmciIDxpcHNlYy1yZXF1ZXN0QGll dGYub3JnPg0KUmVwbHktVG86ICJpcHNlY0BpZXRmLm9yZyIgPGlwc2VjQGlldGYub3JnPg0KRGF0 ZTogV2VkbmVzZGF5LCBKdWx5IDI5LCAyMDIwIGF0IDM6MDEgUE0NClRvOiAiaXBzZWNAaWV0Zi5v cmciIDxpcHNlY0BpZXRmLm9yZz4NClN1YmplY3Q6IFtFWFRFUk5BTF0gSVBzZWMgRGlnZXN0LCBW b2wgMTk1LCBJc3N1ZSAyMg0KDQpbRVhURVJOQUwgU0VOREVSOiBUaGlzIGVtYWlsIG9yaWdpbmF0 ZWQgZnJvbSBvdXRzaWRlIG9mIFN0cmF0dXMgVGVjaG5vbG9naWVzLiBEbyBub3QgY2xpY2sgbGlu a3Mgb3Igb3BlbiBhdHRhY2htZW50cyB1bmxlc3MgeW91IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFu ZCBrbm93IHRoZSBjb250ZW50IGlzIHNhZmUuXQ0KDQpTZW5kIElQc2VjIG1haWxpbmcgbGlzdCBz dWJtaXNzaW9ucyB0bw0KaXBzZWNAaWV0Zi5vcmcNCg0KVG8gc3Vic2NyaWJlIG9yIHVuc3Vic2Ny aWJlIHZpYSB0aGUgV29ybGQgV2lkZSBXZWIsIHZpc2l0DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2lwc2VjPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaXBzZWM+DQpvciwgdmlhIGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3aXRoIHN1YmplY3Qgb3Ig Ym9keSAnaGVscCcgdG8NCmlwc2VjLXJlcXVlc3RAaWV0Zi5vcmcNCg0KWW91IGNhbiByZWFjaCB0 aGUgcGVyc29uIG1hbmFnaW5nIHRoZSBsaXN0IGF0DQppcHNlYy1vd25lckBpZXRmLm9yZw0KDQpX aGVuIHJlcGx5aW5nLCBwbGVhc2UgZWRpdCB5b3VyIFN1YmplY3QgbGluZSBzbyBpdCBpcyBtb3Jl IHNwZWNpZmljDQp0aGFuICJSZTogQ29udGVudHMgb2YgSVBzZWMgZGlnZXN0Li4uIg0KDQoNClRv ZGF5J3MgVG9waWNzOg0KDQoxLiBSZTogVGVhc2VyIGZvciBwaXRjaCB0YWxrIGF0IElFVEYgMTA4 IChTY290dCBGbHVocmVyIChzZmx1aHJlcikpDQoyLiBSZTogVGVhc2VyIGZvciBwaXRjaCB0YWxr IGF0IElFVEYgMTA4IChTY290dCBGbHVocmVyIChzZmx1aHJlcikpDQoNCg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQpNZXNzYWdlOiAxDQpEYXRlOiBXZWQsIDI5IEp1bCAyMDIwIDE4OjUyOjMyICswMDAwDQpG cm9tOiAiU2NvdHQgRmx1aHJlciAoc2ZsdWhyZXIpIiA8c2ZsdWhyZXJAY2lzY28uY29tPg0KVG86 IFRlcm8gS2l2aW5lbiA8a2l2aW5lbkBpa2kuZmk+LCBNaWNoYWVsIFJvc3NiZXJnDQo8bWljaGFl bC5yb3NzYmVyZ0B0dS1pbG1lbmF1LmRlPg0KQ2M6IFN0ZWZmZW4gS2xhc3NlcnQgPHN0ZWZmZW4u a2xhc3NlcnRAc2VjdW5ldC5jb20+LCAiaXBzZWNAaWV0Zi5vcmciDQo8aXBzZWNAaWV0Zi5vcmc+ LCBWYWxlcnkgU215c2xvdiA8c215c2xvdi5pZXRmQGdtYWlsLmNvbT4NClN1YmplY3Q6IFJlOiBb SVBzZWNdIFRlYXNlciBmb3IgcGl0Y2ggdGFsayBhdCBJRVRGIDEwOA0KTWVzc2FnZS1JRDoNCjxC TjdQUjExTUIyNjQxRjE5NjJCOUYxOTA5N0VDMkZEMUZDMTcwMEBCTjdQUjExTUIyNjQxLm5hbXBy ZDExLnByb2Qub3V0bG9vay5jb20+DQoNCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNl dD0idXRmLTgiDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSVBzZWMg PGlwc2VjLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBUZXJvIEtpdmluZW4NCj4gU2Vu dDogV2VkbmVzZGF5LCBKdWx5IDI5LCAyMDIwIDI6MzAgUE0NCj4gVG86IE1pY2hhZWwgUm9zc2Jl cmcgPG1pY2hhZWwucm9zc2JlcmdAdHUtaWxtZW5hdS5kZT4NCj4gQ2M6IFN0ZWZmZW4gS2xhc3Nl cnQgPHN0ZWZmZW4ua2xhc3NlcnRAc2VjdW5ldC5jb20+OyBpcHNlY0BpZXRmLm9yZzsgVmFsZXJ5 DQo+DQo+ID4gTGlrZSB3cml0dGVuIGFscmVhZHk6IEFuIHVucHJlZGljdGFibGUgdmFsdWUgb2Yg MzJiaXQgc2l6ZSBpcyBvZiBubw0KPiA+IHJlYWwgdmFsdWUgZnJvbSBhIGNyeXB0byBwb2ludCBv ZiB2aWV3LiBPbmUgY291bGQgc2ltcGx5IGd1ZXNzIHRoZQ0KPiA+IHZhbHVlIGFuZCBoYXZlIGEg cmVhbGlzdGljIGNoYW5jZSBvZiBiZWluZyByaWdodCBhZnRlciBhIGNvdXBsZSBvZg0KPiA+IHRo b3VzYW5kIHRyaWVzLiBJIGJlbGlldmUgaXQgaXMgb25seSBpbiB0aGUgc3RhbmRhcmQsIGFzIHdp dGggNjQgYml0DQo+ID4gc2VxdWVuY2UgbnVtYmVycyB0aGVyZSB3aGVyZSAzMiBiaXRzIGxlZnQ7 IG5lZWRpbmcgdG8gYmUgZmlsbGVkLg0KPg0KPiBJIHRoaW5rIGl0IGNhbWUgZnJvbSB0aGUgTklT VCBkb2N1bWVudHMgd2hlcmUgaXQgd2FzIGNhbGxlZCBmaXhlZCBmaWVsZC4gVGhlDQo+IGlkZWEg d2FzIHRvIG1ha2Ugc3VyZSB0aGF0IGV2ZW4gaWYgc29tZW9uZSBhY2NpZGVudGx5IHVzZWQgc2Ft ZSBrZXkgdHdpY2UNCj4gZm9yIHR3byBkaWZmZXJlbnQgU0FzLCB0aGlzIHdpbGwgbm90IGNhdXNl IGlzc3VlcywgYXMgdGhhdCBmaXhlZCBmaWVsZCBpcyBnb2luZyB0bw0KPiBiZSB1bmlxdWUgYW55 d2F5cy4NCg0KTm8sIFJGQzQxMDYgKEp1bmUgMjAwNSkgcHJlZGF0ZWQgODAwLTM4RCAoTm92ZW1i ZXIgMjAwNykgYnkgb3ZlciB0d28geWVhcnMuDQoNCkluc3RlYWQsIGl0IHdhcyBpbnNlcnRlZCB0 byBoYXJkZW4gdGhlIHN5c3RlbSBhZ2FpbnN0IG11bHRpdGFyZ2V0IGF0dGFja3MsIGFzIEkgc2Fp ZCBlYXJsaWVyLi4uDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCk1lc3Nh Z2U6IDINCkRhdGU6IFdlZCwgMjkgSnVsIDIwMjAgMTg6NTQ6MTkgKzAwMDANCkZyb206ICJTY290 dCBGbHVocmVyIChzZmx1aHJlcikiIDxzZmx1aHJlckBjaXNjby5jb20+DQpUbzogTWljaGFlbCBS b3NzYmVyZyA8bWljaGFlbC5yb3NzYmVyZ0B0dS1pbG1lbmF1LmRlPg0KQ2M6IGlwc2VjbWUgbWFp bGluZyBsaXN0IDxpcHNlY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbSVBzZWNdIFRlYXNlciBm b3IgcGl0Y2ggdGFsayBhdCBJRVRGIDEwOA0KTWVzc2FnZS1JRDoNCjxCTjdQUjExTUIyNjQxQTEz QTk0Qjk5MjVENkQ1RjNFQjJDMTcwMEBCTjdQUjExTUIyNjQxLm5hbXByZDExLnByb2Qub3V0bG9v ay5jb20+DQoNCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD0idXMtYXNjaWkiDQoN Cg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNaWNoYWVsIFJvc3NiZXJn IDxtaWNoYWVsLnJvc3NiZXJnQHR1LWlsbWVuYXUuZGU+DQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVs eSAyOSwgMjAyMCAyOjM1IFBNDQo+IFRvOiBTY290dCBGbHVocmVyIChzZmx1aHJlcikgPHNmbHVo cmVyQGNpc2NvLmNvbT4NCj4gQ2M6IGlwc2VjbWUgbWFpbGluZyBsaXN0IDxpcHNlY0BpZXRmLm9y Zz4NCj4gU3ViamVjdDogUmU6IFtJUHNlY10gVGVhc2VyIGZvciBwaXRjaCB0YWxrIGF0IElFVEYg MTA4DQo+DQo+ID4NCj4gPiBBY3R1YWxseSwgaXQgZG9lcyBhZGQgdmFsdWUgZnJvbSBhIGNyeXB0 byBwb2ludCBvZiB2aWV3LCBhdCBsZWFzdCBmcm9tIGENCj4gc3BlY2lmaWMgYXR0YWNrLiBJbiBh IG11bHRpdGFyZ2V0IGF0dGFjaywgdGhhdCBpcywgYW4gYXR0YWNrIHdoZXJlIHdlIGFzc3VtZQ0K PiB0aGF0IHRoZSBhdHRhY2tlciBoYXMgZW5jcnlwdGVkIHBhY2tldHMgZnJvbSBhIGxhcmdlIG51 bWJlciBvZiBTQXMsIGFuZCBoaXMNCj4gZ29hbCBpcyB0byByZWNvdmVyIHRoZSBrZXlzIGZvciBh bnkgb25lIG9mIHRoZSBlbmNyeXB0ZWQgcGFja2V0cywgaGVyZSBpcyB3aGF0DQo+IHRoZSBhdHRh Y2tlciBjYW4gZG8gKGFzc3VtaW5nIEdDTSBvciBDaGFDaGEyMC1Qb2x5MTMwNSk7IGlmIGhlIGhh cyBwYWNrZXQNCj4gZW5jcnlwdGVkIHdpdGggZWFjaCBTQSB3aXRoIHRoZSBzYW1lIG5vbmNlLCBo ZSBjYW4gZ3Vlc3MgYSBrZXksIGFuZA0KPiBnZW5lcmF0ZSB0aGUgaW50ZXJuYWwgR0NNL0NoYUNo YTIwIGtleXN0cmVhbSBiYXNlZCBvbiB0aGF0IGtleS9ub25jZQ0KPiBjb21iaW5hdGlvbi4gSGUg Y2FuIHRoZW4gc2NhbiB0aHJvdWdoIGFsbCB0aGUgcGFja2V0cyB0byBzZWUgaWYgdGhlDQo+IGVu Y3J5cHRpb24gbWFrZXMgc2Vuc2UgKG9yIHRoZSBJQ1YgdGFnIHdvcmtzIG91dCk7IHRoaXMgY2Fu IGJlIGRvbmUgZmFyDQo+IGZhc3RlciB0aGFuIGNoZWNraW5nIGVhY2ggcGFja2V0IGluZGl2aWR1 YWxseS4gQXNzdW1pbmcgdGhlIHBhY2tldHMgYXJlDQo+IGVuY3J5cHRlZCB3aXRoIEFFUy0xMjgs IGFuZCB0aGUgYXR0YWNrZXIgaGFzIHBhY2tldHMgZnJvbSAyKipMIFNBcywgdGhlbg0KPiBhZ2Fp bnN0IHRoaXMgYXR0YWNrLCB3ZSBoYXZlIG9ubHkgMTI4LUwgYml0cyBvZiBzZWN1cml0eS4NCj4g Pg0KPiA+IEJ5IGluY2x1ZGluZyAzMiBiaXRzIG9mIHVucHJlZGljdGFibGUgdmFsdWVzLCB3ZSBt YWtlIHRoaXMgYXR0YWNrIDQgYmlsbGlvbg0KPiB0aW1lcyBoYXJkZXIsIGFuZCBmb3IgQUVTLTEy OCwgdGhhdCB3b3VsZCBnaXZlIHVzIDE2MC1MIGJpdHMgb2Ygc2VjdXJpdHkuIFRoaXMNCj4gZG9l c24ndCBhY3R1YWxseSBhZGQgYW55IHNlY3VyaXR5IGFnYWluc3QgYXR0YWNrcyBhZ2FpbnN0IGEg c2luZ2xlIFNBLCBhbmQgdGhlDQo+IHNhbHQgZG9lc24ndCBhY3R1YWxseSBuZWVkIHRvIGJlIHNl Y3JldC4NCj4NCj4gVGhhbmtzIGZvciBjbGFyaWZpY2F0aW9uLiBJIGd1ZXNzIEkgaGF2ZSBiZWVu IHRoaW5raW5nIHRvbyBTQSBjZW50cmljLg0KPiBJbiBmYWN0IHdlIGFsd2F5cyBkaXNjdXNzZWQg QUVTLTI1NiBvbmx5Lg0KPg0KPiBEbyB5b3UgYWdyZWUgdGhhdCBzdGFydGluZyB0aGUgd2luZG93 L3NlbmRlciBJRHMgd2l0aCByYW5kb20gb2Zmc2V0cw0KPiB3b3VsZCBmaXggdGhpcyB3ZWFrbmVz cz8NCg0KWWVzLCBpdCB3b3VsZCBhZGRyZXNzIHRoaXMgd2Vha25lc3MuIE9uIHRoZSBvdGhlciBo YW5kLCB3aXRoIEFFUy0yNTYsIHlvdSBkb24ndCByZWFsbHkgbmVlZCB0aGlzIGFueXdheXMuLi4N Cg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpTdWJqZWN0OiBEaWdlc3Qg Rm9vdGVyDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpJUHNlYyBtYWlsaW5nIGxpc3QNCklQc2VjQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaXBzZWM+DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkVuZCBv ZiBJUHNlYyBEaWdlc3QsIFZvbCAxOTUsIElzc3VlIDIyDQoqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKg0KDQo= --_000_03C8658CD3354DA782728AB50C110A4Astratuscom_ Content-Type: text/html; charset=UTF-8 Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6 MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiXEBEZW5nWGlhbiI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBT dHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05v cm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5rZXJuZWwvZG9jX2NoYW5nZXM8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPklQc2VjICZsdDtpcHNlYy1ib3VuY2VzQGlldGYub3Jn Jmd0OyBvbiBiZWhhbGYgb2YgJnF1b3Q7aXBzZWMtcmVxdWVzdEBpZXRmLm9yZyZxdW90OyAmbHQ7 aXBzZWMtcmVxdWVzdEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5SZXBseS1UbzogPC9iPiZxdW90O2lw c2VjQGlldGYub3JnJnF1b3Q7ICZsdDtpcHNlY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5EYXRlOiA8 L2I+V2VkbmVzZGF5LCBKdWx5IDI5LCAyMDIwIGF0IDM6MDEgUE08YnI+DQo8Yj5UbzogPC9iPiZx dW90O2lwc2VjQGlldGYub3JnJnF1b3Q7ICZsdDtpcHNlY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5T dWJqZWN0OiA8L2I+W0VYVEVSTkFMXSBJUHNlYyBEaWdlc3QsIFZvbCAxOTUsIElzc3VlIDIyPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltFWFRF Uk5BTCBTRU5ERVI6IFRoaXMgZW1haWwgb3JpZ2luYXRlZCBmcm9tIG91dHNpZGUgb2YgU3RyYXR1 cyBUZWNobm9sb2dpZXMuIERvIG5vdCBjbGljayBsaW5rcyBvciBvcGVuIGF0dGFjaG1lbnRzIHVu bGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2Fm ZS5dPGJyPg0KPGJyPg0KU2VuZCBJUHNlYyBtYWlsaW5nIGxpc3Qgc3VibWlzc2lvbnMgdG88YnI+ DQppcHNlY0BpZXRmLm9yZzxicj4NCjxicj4NClRvIHN1YnNjcmliZSBvciB1bnN1YnNjcmliZSB2 aWEgdGhlIFdvcmxkIFdpZGUgV2ViLCB2aXNpdDxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaXBzZWM8L2E+PGJyPg0Kb3IsIHZpYSBlbWFpbCwgc2VuZCBhIG1lc3NhZ2Ug d2l0aCBzdWJqZWN0IG9yIGJvZHkgJ2hlbHAnIHRvPGJyPg0KaXBzZWMtcmVxdWVzdEBpZXRmLm9y Zzxicj4NCjxicj4NCllvdSBjYW4gcmVhY2ggdGhlIHBlcnNvbiBtYW5hZ2luZyB0aGUgbGlzdCBh dDxicj4NCmlwc2VjLW93bmVyQGlldGYub3JnPGJyPg0KPGJyPg0KV2hlbiByZXBseWluZywgcGxl YXNlIGVkaXQgeW91ciBTdWJqZWN0IGxpbmUgc28gaXQgaXMgbW9yZSBzcGVjaWZpYzxicj4NCnRo YW4gJnF1b3Q7UmU6IENvbnRlbnRzIG9mIElQc2VjIGRpZ2VzdC4uLiZxdW90Ozxicj4NCjxicj4N Cjxicj4NClRvZGF5J3MgVG9waWNzOjxicj4NCjxicj4NCjEuIFJlOiBUZWFzZXIgZm9yIHBpdGNo IHRhbGsgYXQgSUVURiAxMDggKFNjb3R0IEZsdWhyZXIgKHNmbHVocmVyKSk8YnI+DQoyLiBSZTog VGVhc2VyIGZvciBwaXRjaCB0YWxrIGF0IElFVEYgMTA4IChTY290dCBGbHVocmVyIChzZmx1aHJl cikpPGJyPg0KPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCjxicj4NCk1lc3NhZ2U6IDE8 YnI+DQpEYXRlOiBXZWQsIDI5IEp1bCAyMDIwIDE4OjUyOjMyICswMDAwPGJyPg0KRnJvbTogJnF1 b3Q7U2NvdHQgRmx1aHJlciAoc2ZsdWhyZXIpJnF1b3Q7ICZsdDtzZmx1aHJlckBjaXNjby5jb20m Z3Q7PGJyPg0KVG86IFRlcm8gS2l2aW5lbiAmbHQ7a2l2aW5lbkBpa2kuZmkmZ3Q7LCBNaWNoYWVs IFJvc3NiZXJnPGJyPg0KJmx0O21pY2hhZWwucm9zc2JlcmdAdHUtaWxtZW5hdS5kZSZndDs8YnI+ DQpDYzogU3RlZmZlbiBLbGFzc2VydCAmbHQ7c3RlZmZlbi5rbGFzc2VydEBzZWN1bmV0LmNvbSZn dDssICZxdW90O2lwc2VjQGlldGYub3JnJnF1b3Q7PGJyPg0KJmx0O2lwc2VjQGlldGYub3JnJmd0 OywgVmFsZXJ5IFNteXNsb3YgJmx0O3NteXNsb3YuaWV0ZkBnbWFpbC5jb20mZ3Q7PGJyPg0KU3Vi amVjdDogUmU6IFtJUHNlY10gVGVhc2VyIGZvciBwaXRjaCB0YWxrIGF0IElFVEYgMTA4PGJyPg0K TWVzc2FnZS1JRDo8YnI+DQombHQ7Qk43UFIxMU1CMjY0MUYxOTYyQjlGMTkwOTdFQzJGRDFGQzE3 MDBAQk43UFIxMU1CMjY0MS5uYW1wcmQxMS5wcm9kLm91dGxvb2suY29tJmd0Ozxicj4NCjxicj4N CkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD0mcXVvdDt1dGYtOCZxdW90Ozxicj4N Cjxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IElQ c2VjICZsdDtpcHNlYy1ib3VuY2VzQGlldGYub3JnJmd0OyBPbiBCZWhhbGYgT2YgVGVybyBLaXZp bmVuPGJyPg0KJmd0OyBTZW50OiBXZWRuZXNkYXksIEp1bHkgMjksIDIwMjAgMjozMCBQTTxicj4N CiZndDsgVG86IE1pY2hhZWwgUm9zc2JlcmcgJmx0O21pY2hhZWwucm9zc2JlcmdAdHUtaWxtZW5h dS5kZSZndDs8YnI+DQomZ3Q7IENjOiBTdGVmZmVuIEtsYXNzZXJ0ICZsdDtzdGVmZmVuLmtsYXNz ZXJ0QHNlY3VuZXQuY29tJmd0OzsgaXBzZWNAaWV0Zi5vcmc7IFZhbGVyeTxicj4NCiZndDsgPGJy Pg0KJmd0OyAmZ3Q7IExpa2Ugd3JpdHRlbiBhbHJlYWR5OiBBbiB1bnByZWRpY3RhYmxlIHZhbHVl IG9mIDMyYml0IHNpemUgaXMgb2Ygbm88YnI+DQomZ3Q7ICZndDsgcmVhbCB2YWx1ZSBmcm9tIGEg Y3J5cHRvIHBvaW50IG9mIHZpZXcuIE9uZSBjb3VsZCBzaW1wbHkgZ3Vlc3MgdGhlPGJyPg0KJmd0 OyAmZ3Q7IHZhbHVlIGFuZCBoYXZlIGEgcmVhbGlzdGljIGNoYW5jZSBvZiBiZWluZyByaWdodCBh ZnRlciBhIGNvdXBsZSBvZjxicj4NCiZndDsgJmd0OyB0aG91c2FuZCB0cmllcy4gSSBiZWxpZXZl IGl0IGlzIG9ubHkgaW4gdGhlIHN0YW5kYXJkLCBhcyB3aXRoIDY0IGJpdDxicj4NCiZndDsgJmd0 OyBzZXF1ZW5jZSBudW1iZXJzIHRoZXJlIHdoZXJlIDMyIGJpdHMgbGVmdDsgbmVlZGluZyB0byBi ZSBmaWxsZWQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgdGhpbmsgaXQgY2FtZSBmcm9tIHRoZSBO SVNUIGRvY3VtZW50cyB3aGVyZSBpdCB3YXMgY2FsbGVkIGZpeGVkIGZpZWxkLiBUaGU8YnI+DQom Z3Q7IGlkZWEgd2FzIHRvIG1ha2Ugc3VyZSB0aGF0IGV2ZW4gaWYgc29tZW9uZSBhY2NpZGVudGx5 IHVzZWQgc2FtZSBrZXkgdHdpY2U8YnI+DQomZ3Q7IGZvciB0d28gZGlmZmVyZW50IFNBcywgdGhp cyB3aWxsIG5vdCBjYXVzZSBpc3N1ZXMsIGFzIHRoYXQgZml4ZWQgZmllbGQgaXMgZ29pbmcgdG88 YnI+DQomZ3Q7IGJlIHVuaXF1ZSBhbnl3YXlzLjxicj4NCjxicj4NCk5vLCBSRkM0MTA2IChKdW5l IDIwMDUpIHByZWRhdGVkIDgwMC0zOEQgKE5vdmVtYmVyIDIwMDcpIGJ5IG92ZXIgdHdvIHllYXJz Ljxicj4NCjxicj4NCkluc3RlYWQsIGl0IHdhcyBpbnNlcnRlZCB0byBoYXJkZW4gdGhlIHN5c3Rl bSBhZ2FpbnN0IG11bHRpdGFyZ2V0IGF0dGFja3MsIGFzIEkgc2FpZCBlYXJsaWVyLi4uPGJyPg0K PGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KTWVz c2FnZTogMjxicj4NCkRhdGU6IFdlZCwgMjkgSnVsIDIwMjAgMTg6NTQ6MTkgKzAwMDA8YnI+DQpG cm9tOiAmcXVvdDtTY290dCBGbHVocmVyIChzZmx1aHJlcikmcXVvdDsgJmx0O3NmbHVocmVyQGNp c2NvLmNvbSZndDs8YnI+DQpUbzogTWljaGFlbCBSb3NzYmVyZyAmbHQ7bWljaGFlbC5yb3NzYmVy Z0B0dS1pbG1lbmF1LmRlJmd0Ozxicj4NCkNjOiBpcHNlY21lIG1haWxpbmcgbGlzdCAmbHQ7aXBz ZWNAaWV0Zi5vcmcmZ3Q7PGJyPg0KU3ViamVjdDogUmU6IFtJUHNlY10gVGVhc2VyIGZvciBwaXRj aCB0YWxrIGF0IElFVEYgMTA4PGJyPg0KTWVzc2FnZS1JRDo8YnI+DQombHQ7Qk43UFIxMU1CMjY0 MUExM0E5NEI5OTI1RDZENUYzRUIyQzE3MDBAQk43UFIxMU1CMjY0MS5uYW1wcmQxMS5wcm9kLm91 dGxvb2suY29tJmd0Ozxicj4NCjxicj4NCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNl dD0mcXVvdDt1cy1hc2NpaSZxdW90Ozxicj4NCjxicj4NCjxicj4NCiZndDsgLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IE1pY2hhZWwgUm9zc2JlcmcgJmx0O21pY2hh ZWwucm9zc2JlcmdAdHUtaWxtZW5hdS5kZSZndDs8YnI+DQomZ3Q7IFNlbnQ6IFdlZG5lc2RheSwg SnVseSAyOSwgMjAyMCAyOjM1IFBNPGJyPg0KJmd0OyBUbzogU2NvdHQgRmx1aHJlciAoc2ZsdWhy ZXIpICZsdDtzZmx1aHJlckBjaXNjby5jb20mZ3Q7PGJyPg0KJmd0OyBDYzogaXBzZWNtZSBtYWls aW5nIGxpc3QgJmx0O2lwc2VjQGlldGYub3JnJmd0Ozxicj4NCiZndDsgU3ViamVjdDogUmU6IFtJ UHNlY10gVGVhc2VyIGZvciBwaXRjaCB0YWxrIGF0IElFVEYgMTA4PGJyPg0KJmd0OyA8YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgQWN0dWFsbHksIGl0IGRvZXMgYWRkIHZhbHVlIGZyb20g YSBjcnlwdG8gcG9pbnQgb2YgdmlldywgYXQgbGVhc3QgZnJvbSBhPGJyPg0KJmd0OyBzcGVjaWZp YyBhdHRhY2suIEluIGEgbXVsdGl0YXJnZXQgYXR0YWNrLCB0aGF0IGlzLCBhbiBhdHRhY2sgd2hl cmUgd2UgYXNzdW1lPGJyPg0KJmd0OyB0aGF0IHRoZSBhdHRhY2tlciBoYXMgZW5jcnlwdGVkIHBh Y2tldHMgZnJvbSBhIGxhcmdlIG51bWJlciBvZiBTQXMsIGFuZCBoaXM8YnI+DQomZ3Q7IGdvYWwg aXMgdG8gcmVjb3ZlciB0aGUga2V5cyBmb3IgYW55IG9uZSBvZiB0aGUgZW5jcnlwdGVkIHBhY2tl dHMsIGhlcmUgaXMgd2hhdDxicj4NCiZndDsgdGhlIGF0dGFja2VyIGNhbiBkbyAoYXNzdW1pbmcg R0NNIG9yIENoYUNoYTIwLVBvbHkxMzA1KTsgaWYgaGUgaGFzIHBhY2tldDxicj4NCiZndDsgZW5j cnlwdGVkIHdpdGggZWFjaCBTQSB3aXRoIHRoZSBzYW1lIG5vbmNlLCBoZSBjYW4gZ3Vlc3MgYSBr ZXksIGFuZDxicj4NCiZndDsgZ2VuZXJhdGUgdGhlIGludGVybmFsIEdDTS9DaGFDaGEyMCBrZXlz dHJlYW0gYmFzZWQgb24gdGhhdCBrZXkvbm9uY2U8YnI+DQomZ3Q7IGNvbWJpbmF0aW9uLiBIZSBj YW4gdGhlbiBzY2FuIHRocm91Z2ggYWxsIHRoZSBwYWNrZXRzIHRvIHNlZSBpZiB0aGU8YnI+DQom Z3Q7IGVuY3J5cHRpb24gbWFrZXMgc2Vuc2UgKG9yIHRoZSBJQ1YgdGFnIHdvcmtzIG91dCk7IHRo aXMgY2FuIGJlIGRvbmUgZmFyPGJyPg0KJmd0OyBmYXN0ZXIgdGhhbiBjaGVja2luZyBlYWNoIHBh Y2tldCBpbmRpdmlkdWFsbHkuIEFzc3VtaW5nIHRoZSBwYWNrZXRzIGFyZTxicj4NCiZndDsgZW5j cnlwdGVkIHdpdGggQUVTLTEyOCwgYW5kIHRoZSBhdHRhY2tlciBoYXMgcGFja2V0cyBmcm9tIDIq KkwgU0FzLCB0aGVuPGJyPg0KJmd0OyBhZ2FpbnN0IHRoaXMgYXR0YWNrLCB3ZSBoYXZlIG9ubHkg MTI4LUwgYml0cyBvZiBzZWN1cml0eS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgQnkg aW5jbHVkaW5nIDMyIGJpdHMgb2YgdW5wcmVkaWN0YWJsZSB2YWx1ZXMsIHdlIG1ha2UgdGhpcyBh dHRhY2sgNCBiaWxsaW9uPGJyPg0KJmd0OyB0aW1lcyBoYXJkZXIsIGFuZCBmb3IgQUVTLTEyOCwg dGhhdCB3b3VsZCBnaXZlIHVzIDE2MC1MIGJpdHMgb2Ygc2VjdXJpdHkuIFRoaXM8YnI+DQomZ3Q7 IGRvZXNuJ3QgYWN0dWFsbHkgYWRkIGFueSBzZWN1cml0eSBhZ2FpbnN0IGF0dGFja3MgYWdhaW5z dCBhIHNpbmdsZSBTQSwgYW5kIHRoZTxicj4NCiZndDsgc2FsdCBkb2Vzbid0IGFjdHVhbGx5IG5l ZWQgdG8gYmUgc2VjcmV0Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGFua3MgZm9yIGNsYXJpZmlj YXRpb24uIEkgZ3Vlc3MgSSBoYXZlIGJlZW4gdGhpbmtpbmcgdG9vIFNBIGNlbnRyaWMuPGJyPg0K Jmd0OyBJbiBmYWN0IHdlIGFsd2F5cyBkaXNjdXNzZWQgQUVTLTI1NiBvbmx5Ljxicj4NCiZndDsg PGJyPg0KJmd0OyBEbyB5b3UgYWdyZWUgdGhhdCBzdGFydGluZyB0aGUgd2luZG93L3NlbmRlciBJ RHMgd2l0aCByYW5kb20gb2Zmc2V0czxicj4NCiZndDsgd291bGQgZml4IHRoaXMgd2Vha25lc3M/ PGJyPg0KPGJyPg0KWWVzLCBpdCB3b3VsZCBhZGRyZXNzIHRoaXMgd2Vha25lc3MuIE9uIHRoZSBv dGhlciBoYW5kLCB3aXRoIEFFUy0yNTYsIHlvdSBkb24ndCByZWFsbHkgbmVlZCB0aGlzIGFueXdh eXMuLi48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS08YnI+DQo8YnI+DQpTdWJqZWN0OiBEaWdlc3QgRm9vdGVyPGJyPg0KPGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJUHNlYyBtYWlsaW5n IGxpc3Q8YnI+DQpJUHNlY0BpZXRmLm9yZzxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaXBzZWM8L2E+PGJyPg0KPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPGJyPg0KPGJyPg0KRW5kIG9mIElQc2VjIERpZ2VzdCwgVm9sIDE5NSwgSXNzdWUg MjI8YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4NCjxicj4N CjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_03C8658CD3354DA782728AB50C110A4Astratuscom_-- From nobody Wed Jul 29 12:20:41 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679A93A0E3B for ; Wed, 29 Jul 2020 12:20:39 -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=unavailable 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 yBPiCtT_OTrk for ; Wed, 29 Jul 2020 12:20:36 -0700 (PDT) Received: from meesny.iki.fi (meesny.iki.fi [IPv6:2001:67c:2b0:1c1::201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 672763A0E3C for ; Wed, 29 Jul 2020 12:20:35 -0700 (PDT) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: kivinen) by meesny.iki.fi (Postfix) with ESMTPSA id E9AF42008C; Wed, 29 Jul 2020 22:20:33 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1596050433; 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=9s+QcQAjAFay+rCs78bVYsEubBzr3IfTS8ndj8vftf8=; b=FW4TCwRWIaSzwtIxyoV8t7LgSiLVZOydODZCx8zFwQH5H2RilqcSfElDIPiYxOn/FZSOb6 f3SdUZzg8U5nu8tJEURm/BbQy9red5PsBEjsZVoEQ9FlkGe30ghcbIScR5bDR6Ih4N5bz4 8PDeT5OdEOzpoolS/xV6sxkLcSGmab4= Received: by fireball.acr.fi (Postfix, from userid 15204) id A5CB425C1377; Wed, 29 Jul 2020 22:20:33 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24353.52225.632384.30387@fireball.acr.fi> Date: Wed, 29 Jul 2020 22:20:33 +0300 From: Tero Kivinen To: "Scott Fluhrer \(sfluhrer\)" Cc: Michael Rossberg , Steffen Klassert , "ipsec\@ietf.org" , Valery Smyslov In-Reply-To: References: <023E45E1-B1AA-4042-A8E3-DD7457235BC7@tu-ilmenau.de> <0fd501d664b6$fcc8c590$f65a50b0$@gmail.com> <20200729100457.GD20687@gauss3.secunet.de> <24353.30727.115426.454334@fireball.acr.fi> <24353.49189.175868.584478@fireball.acr.fi> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 4 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1596050433; 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=9s+QcQAjAFay+rCs78bVYsEubBzr3IfTS8ndj8vftf8=; b=gTG+QJdUbib2e5HEFNFLLDMqsxyDLSFxwRbSga3pMbY28/YDVvfx9/uyXQU39yQKvFXSQ/ 5DsYzWFDW6Y88CAQJAPniZxj4sNFAr/6Wu7CoNpSI5Oanv05VEBXXQznTY9WZJI68d5LeS 1LtQhanI/bOO2aAlfR9WXmLDL/zu2SA= ARC-Seal: i=1; s=meesny; d=iki.fi; t=1596050434; a=rsa-sha256; cv=none; b=NHXCgJ6tD//xZcJExC+F/MIRJAoaYd9BW5y4N0DYONhp+qTpozV5Dr4O6m03fhzveJKfhD iVoEukTJzS5nBv3i13LYLqpkg8357JG+b3s8ccNhc5bRWQhXMZm3tiVHrR484M8Rsnb6nI LxlZiavU6JXZ4aOEyM7obUPFZnIITws= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [IPsec] Teaser for pitch talk at IETF 108 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, 29 Jul 2020 19:20:40 -0000 Scott Fluhrer \(sfluhrer\) writes: > No, RFC4106 (June 2005) predated 800-38D (November 2007) by over two years. Ah, didn't check the dates, and the NIST document didn't really explain the reason behind it, it just said you preferrably need to have 32-bit fixed part. > Instead, it was inserted to harden the system against multitarget > attacks, as I said earlier... Thanks for that explination. So we do want to keep that, and of course as it is part of NIST document you might have issues trying to get certifications for you implementations if you do not follow NIST documents. You most likely would still get certification even if you do not follow some RFCs. -- kivinen@iki.fi From nobody Thu Jul 30 01:07:32 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D183F3A0F8E for ; Thu, 30 Jul 2020 01:07:29 -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 2oZkrysDbojc for ; Thu, 30 Jul 2020 01:07:28 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 CB3BB3A0F9A for ; Thu, 30 Jul 2020 01:07:19 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id r19so27856276ljn.12 for ; Thu, 30 Jul 2020 01:07:19 -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=RRl8DVjN8kYvP1gAqRL5sKKUgPMs9BMiZmwU3NJOEA8=; b=NJ9dNGIFSm3v+gowB39N0DVeiZvvROSiIE4zhpgVWPYYCZVFiEEGYitA+ixagX6scY thI6XPW/SJS4s54WeY7zB4cQM6cPSmQpUAd/UEfRN2SJzdgaGKjSkVnY7TLlEH/z+CaA B4pv8RTxV3QvN3jWND/Iv05XFBFprYa3U5rMzb/9Ea6kukVok4NbUXYrxz6gBIO5QImU R8BGs4dHzuZuLavBgQOHmaiCEqFlOmRyXGzQ2D3vJCPFx1bNJXsLga/drMgb9XSq23he nzMNObz6an9v8n9JQpSc9a9p2ovttWWr2/uHkhGln4xI1KeDoBcBar1aRkmYS1N0O9sg K81Q== 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=RRl8DVjN8kYvP1gAqRL5sKKUgPMs9BMiZmwU3NJOEA8=; b=ayg8uKNF6+7HL+uDzLTkjepFsMqig51S7zPzAoC1G1c8TJw27lbljG/D830pBh1K9r 8sHCM30jtTnIer8wnchBfiFn16/UPM6nFm0tQqynxMi2mYycqN2DNs0zhWjridzVhcnv gE5OE7fePOYHX9+Ma/g1jY/7202NK4eXXdU9OeKih1URNfMmGeWX783BFOzxfHbojB2i 3TcymMMk1bU2OCd6K8waHwpVe+rQE3xbb6Qr+xi63ehlKufOCW6TsZoViR/ORqeUTW0U CrtSZyoHmxicWymuRSIJP45HHI/qKmuqws/Vsg0J+ruuGjAr/rWqhmxfghGs/b/AMNMb qIBQ== X-Gm-Message-State: AOAM533Frno6elyPbk/pqyownLRKt0eeY4V8YQWPI+o+5nxE3d34iIOb xEX7LG71y1RWzIkunyQBJ/MBSpg1 X-Google-Smtp-Source: ABdhPJwNKcWnb3zudT3Ex06Z5jRLih/6IDRUZE/uYogyGa6PBqHSnT836UBzPPf216juwM9ftUlw8Q== X-Received: by 2002:a2e:9bc1:: with SMTP id w1mr997625ljj.288.1596096437227; Thu, 30 Jul 2020 01:07:17 -0700 (PDT) Received: from buildpc ([82.138.51.3]) by smtp.gmail.com with ESMTPSA id b18sm1220141lfp.36.2020.07.30.01.07.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Jul 2020 01:07:16 -0700 (PDT) From: "Valery Smyslov" To: "'Scott Fluhrer \(sfluhrer\)'" , "'Michael Rossberg'" Cc: "'ipsecme mailing list'" References: <023E45E1-B1AA-4042-A8E3-DD7457235BC7@tu-ilmenau.de> <0fd501d664b6$fcc8c590$f65a50b0$@gmail.com> <20200729100457.GD20687@gauss3.secunet.de> <24353.30727.115426.454334@fireball.acr.fi> <25B2E4EE-6A2B-4324-B16C-DFCB54AC9E87@tu-ilmenau.de> In-Reply-To: Date: Thu, 30 Jul 2020 11:07:18 +0300 Message-ID: <14a101d66648$72367ba0$56a372e0$@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: AQLb8KjJ82/eUG4ib/oDCzGyVFFVxgLfnTVzAk0veW8CU2x12gKX87jhAcB+nhIBWFvTXwFotONIpp/fDhA= Content-Language: ru Archived-At: Subject: Re: [IPsec] Teaser for pitch talk at IETF 108 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, 30 Jul 2020 08:07:30 -0000 Hi Scott, > > > Actually, it does add value from a crypto point of view, at least from a > > specific attack. In a multitarget attack, that is, an attack where we assume > > that the attacker has encrypted packets from a large number of SAs, and his > > goal is to recover the keys for any one of the encrypted packets, here is what > > the attacker can do (assuming GCM or ChaCha20-Poly1305); if he has packet > > encrypted with each SA with the same nonce, he can guess a key, and > > generate the internal GCM/ChaCha20 keystream based on that key/nonce > > combination. He can then scan through all the packets to see if the > > encryption makes sense (or the ICV tag works out); this can be done far > > faster than checking each packet individually. Assuming the packets are > > encrypted with AES-128, and the attacker has packets from 2**L SAs, then > > against this attack, we have only 128-L bits of security. > > > > > > By including 32 bits of unpredictable values, we make this attack 4 billion > > times harder, and for AES-128, that would give us 160-L bits of security. This > > doesn't actually add any security against attacks against a single SA, and the > > salt doesn't actually need to be secret. Thank you for the good explanation. > > Thanks for clarification. I guess I have been thinking too SA centric. > > In fact we always discussed AES-256 only. > > > > Do you agree that starting the window/sender IDs with random offsets > > would fix this weakness? > > Yes, it would address this weakness. On the other hand, with AES-256, you don't really need this anyways... What's your opinion - if we consider quantum computers (so that the real strength of AES-256 is 128 bit), then does addition of unpredicted salt to AES-256 make sense? Regards, Valery. > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Jul 30 11:01:22 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D81B83A1199 for ; Thu, 30 Jul 2020 11:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=ilTxPQiA; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=VFYc3OSB 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 ogyTMAzj8Iqy for ; Thu, 30 Jul 2020 11:01:02 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDCDA3A110A for ; Thu, 30 Jul 2020 11:00:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4769; q=dns/txt; s=iport; t=1596132030; x=1597341630; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=HhMbGYjMmqPgktfugkf64RYvybXDQjDhrzF8+apFY6M=; b=ilTxPQiAAXprWO+niGr2A2yL2xTskFKJ0VMnup63peCHyYNV+qZ6nNLx 8KENQ+xTyQVf1WgAEzISDKIHZNGAHFFF6uSdCCMxeb/lM9iu5D1fYhTLK HHM/IpNrAYpVgB41b6G6CUzsJ9oyOMkVNckt6IpuilOt2ydoaMp7HzIoI k=; IronPort-PHdr: =?us-ascii?q?9a23=3AFaFMSR+KJK2QxP9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+7ZRCN6vBkjVuPVoLeuLpIiOvT5qbnX2FIoZOMq2sLf5EEUR?= =?us-ascii?q?gZwd4XkAotDI/gawX7IffmYjZ8EJFEU1lorH6+OElRXs35Yg6arni79zVHHB?= =?us-ascii?q?L5OEJ8Lfj0HYiHicOx2qiy9pTfbh8OiiC6ZOZ5LQ69qkPascxFjA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DXAQA7CiNf/5FdJa1gGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAUCBSoFSKSgHgUcvLAqHcQONT4oDjl+CUwNVCwEBAQw?= =?us-ascii?q?BAS0CBAEBhEwCgi4CJDgTAgMBAQsBAQUBAQECAQYEbYVcDIVxAQEBBBIoBgE?= =?us-ascii?q?BLAsBCwQCAQgRBAEBHxAhER0IAgQBDQUIGoVQAy4BpV0CgTmIYXSBNIMBAQE?= =?us-ascii?q?FhRcNC4IOCYE4AYJuh1OBCIEmHRqBQT+BVIIfLj6BBIEWgiWDR4IttBuBIk4?= =?us-ascii?q?Kgl+VBoUan3SSH40UkgsCBAIEBQIOAQEFgWojgVdwFTuCaVAXAg2OHwwXgQI?= =?us-ascii?q?BCYJCilZ0NwIGCAEBAwl8jksBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.75,415,1589241600"; d="scan'208";a="531890970" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Jul 2020 18:00:29 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 06UI0SiL010508 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 30 Jul 2020 18:00:29 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 30 Jul 2020 13:00:25 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 30 Jul 2020 13:00:25 -0500 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 30 Jul 2020 14:00:25 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mzeYYPzF0NIKZ0T3yH7MPK45K6EdRYqiZq2g4MyMEg2IoKFJTANqEXwVSTFsZOy8t85CJoksJt/mlFBbGmnqm6p6MbjrQJfcsrpRm8EC/eX5UHDf+iIKrLBtl5X5KK0Mojo9I+62lSpgxQkCWib2HvdL2dnFmoDffsyr54Gs1C/GqkcMvbShFss1U7XX/UH9fZHiF7rcS+2br5eCd99ZBIai1MghXFUAxkYFhReRlp91ZLhdx0VEDIoSKVE+R5KSDmAuzb+1WEu1eH24iP7kVbkOVhynWDRxdLRA0ubGvE43se7Zc6+lTn04qroRZz7JI61Y3o7QFnT+c6JavlCJOA== 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=x/JgNSL60QFE7Po/W5yMPcwl8iuWHZAV8Rcpj134JOQ=; b=h+rGUt72WrrbJNHzOtLfXOoSYiqUzHkmYz+T2OW6TdSvMPz7kDH/4hEjzXR3sDu6MHB4916bnwJCSCaWprvSVpQh95sON0j6Va8E4dR1/QiyjJUhNqEzSN/dmxYl2TcVzy6Cc2HJ1trRtRd+WgqLkPAlVIwTPc8aqy9OPb5B1z7VV0B/Xx1F2JAU+u4cN1EoVvQk1Cuwku/lRkz5AGLnVKGqsLGiOblRmKYtGL5TCOkHq9bo5xQRzbDYsWAMaWk8qcHQ0q1Po/A7if51clCYngUE4WRB3NrjllUmbU8p9yqad/iKXCY9murzMc21Bo9wPhis4a1j3TiW/9RhfAbHpw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=x/JgNSL60QFE7Po/W5yMPcwl8iuWHZAV8Rcpj134JOQ=; b=VFYc3OSBM8Yg9yzb9yQezAm0yq46l38FFlH5oPHdocoz5zzVh+ZKBIUcAnh6S3QHvJtKs/XXYhlr0DMCoDpucXAbnZVsB+TimHjnmLRZeVhFD5DqOObsWeO+s1ndlEBmf3LV1hvobyyyHTJ7drIiAAb6fWfQPqQZ4VtAmn1AJrE= Received: from BN7PR11MB2641.namprd11.prod.outlook.com (2603:10b6:406:b1::25) by BN6PR11MB3937.namprd11.prod.outlook.com (2603:10b6:405:77::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.17; Thu, 30 Jul 2020 18:00:24 +0000 Received: from BN7PR11MB2641.namprd11.prod.outlook.com ([fe80::5018:edeb:b77d:4d65]) by BN7PR11MB2641.namprd11.prod.outlook.com ([fe80::5018:edeb:b77d:4d65%3]) with mapi id 15.20.3216.034; Thu, 30 Jul 2020 18:00:24 +0000 From: "Scott Fluhrer (sfluhrer)" To: Valery Smyslov , "'Michael Rossberg'" CC: "'ipsecme mailing list'" Thread-Topic: [IPsec] Teaser for pitch talk at IETF 108 Thread-Index: AQHWYBKzgiV8IDTYWUmmokuEibQdmKkcrdKAgAGxdYCAADcggIAALvYAgAAEYRCAACQXAIAABPjwgADd8ACAAJJfEA== Date: Thu, 30 Jul 2020 18:00:24 +0000 Message-ID: References: <023E45E1-B1AA-4042-A8E3-DD7457235BC7@tu-ilmenau.de> <0fd501d664b6$fcc8c590$f65a50b0$@gmail.com> <20200729100457.GD20687@gauss3.secunet.de> <24353.30727.115426.454334@fireball.acr.fi> <25B2E4EE-6A2B-4324-B16C-DFCB54AC9E87@tu-ilmenau.de> <14a101d66648$72367ba0$56a372e0$@gmail.com> In-Reply-To: <14a101d66648$72367ba0$56a372e0$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.78] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 353c0bdf-430b-44a4-96e9-08d834b26f2a x-ms-traffictypediagnostic: BN6PR11MB3937: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zlsxh2WRASzYuXQqBeeO80QHIJXB4iGqzYZ2uI2Fg5YVdF1k2Yill3Xa7IzRRnJsZW5jdeFmYnrn96O1QgLdJobn4ywB6cWwfM6lvetEZkPiVdej1wFEIO09zRKILmO5JgutUP2/Cd+6Xuqa4oLPBkKxR/XlWL08p09RleJtQiSiuGD3t4FyXM8dxLYpVdLu3uOEsSTKwGToxTC+YgBiAKChni0y0/ZmQ2Wm9NuRaWQQ1NEaoCArZZ/+G/jYa9sQwzEO/uiaYJ4R78AeRi9GuNA8zV3AkG9RgDe9PKoNheVSeHx3o5s+KSjZS7+7oYWUbwJIIWViM6KqpQ0kTBeLeg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2641.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(366004)(376002)(39860400002)(346002)(7696005)(110136005)(5660300002)(316002)(52536014)(33656002)(83380400001)(26005)(53546011)(8676002)(478600001)(8936002)(4326008)(2906002)(9686003)(55016002)(186003)(86362001)(64756008)(66556008)(76116006)(66946007)(66446008)(71200400001)(66476007)(6506007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: xBw8vH/fH8cWP+tAjauaDNp3R1ADKHzPIb+hCY+lKVz76E3LvLHOW60kOkx0X7eVyG5+J7f58RvcpkGvRxKewEJqH7AfnaPOWxI7WxeMjf5Nc8Cf2QTk9JdVNL9+PUIZktU2TnIDiPs4gPkc/xPqnKWoGMBe8htt6bzqKR6oKxFTxDooKo+AMBFv7y4DLDVwNwL7NR+bsVOInuJLBNnV0NepbMALMk0Ehzpymif+VAgLnc9LaAmpF4/NhDpYsL/P1IE4Y5XXPSx9aHoTQBvXxNZnqNRIeXZxVANqVlDkjVQ0y5pSOb8d8cxmX7T1XK4Ws8WedIVygkYzsvnSXD1fLE0bu2nV0HNxxmym6OdukpbTEDBIthFLYTdsSUuC79+i5NRxkr+6Adimx4UAaEpA/pMox6SoSjxIfgg9lUJUcSFoeD20EQvYsfyDMT77iTc/by9vpmnTYXWor2xnNd2ONPNmsTaEwSIvbsaJwfpbQDtZDRWPLR9SHW+hiKSJiTOjHzZdfNtlc0L5xWZyZQEPTxcmD67apO8OKz3K3ht9UNW0jEsc8Wogrl3gF2ds1AhBx5YrSDh8Vz7eduHmN3dyOY8QXwOqoKZV/QlYLu/u3AcmIYQM8M2Jbv2f6hfP9odBTvLjFDAVXBn9Bvchwza5vA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN7PR11MB2641.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 353c0bdf-430b-44a4-96e9-08d834b26f2a X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2020 18:00:24.5011 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: OgDNB7EFBivhLXVNGvyvQOL72vgnpO4akr5Cdo4h3YDLNugt+7oYUAjxLLVX2DNBLdYFyEiA25094oAjmXWI4g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB3937 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [IPsec] Teaser for pitch talk at IETF 108 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, 30 Jul 2020 18:01:20 -0000 > -----Original Message----- > From: Valery Smyslov > Sent: Thursday, July 30, 2020 4:07 AM > To: Scott Fluhrer (sfluhrer) ; 'Michael Rossberg' > > Cc: 'ipsecme mailing list' > Subject: RE: [IPsec] Teaser for pitch talk at IETF 108 >=20 > Hi Scott, >=20 > > > > Actually, it does add value from a crypto point of view, at least > > > > from a > > > specific attack. In a multitarget attack, that is, an attack where > > > we assume that the attacker has encrypted packets from a large > > > number of SAs, and his goal is to recover the keys for any one of > > > the encrypted packets, here is what the attacker can do (assuming > > > GCM or ChaCha20-Poly1305); if he has packet encrypted with each SA > > > with the same nonce, he can guess a key, and generate the internal > > > GCM/ChaCha20 keystream based on that key/nonce combination. He > can > > > then scan through all the packets to see if the encryption makes > > > sense (or the ICV tag works out); this can be done far faster than > > > checking each packet individually. Assuming the packets are > > > encrypted with AES-128, and the attacker has packets from 2**L SAs, > then against this attack, we have only 128-L bits of security. > > > > > > > > By including 32 bits of unpredictable values, we make this attack > > > > 4 billion > > > times harder, and for AES-128, that would give us 160-L bits of > > > security. This doesn't actually add any security against attacks > > > against a single SA, and the salt doesn't actually need to be secret. >=20 > Thank you for the good explanation. >=20 > > > Thanks for clarification. I guess I have been thinking too SA centric= . > > > In fact we always discussed AES-256 only. > > > > > > Do you agree that starting the window/sender IDs with random offsets > > > would fix this weakness? > > > > Yes, it would address this weakness. On the other hand, with AES-256, = you > don't really need this anyways... >=20 > What's your opinion - if we consider quantum computers (so that the real > strength of AES-256 is 128 bit), then does addition of unpredicted salt t= o AES- > 256 make sense? That is a surprisingly deep question; however since you specified "my opini= on", I would say "it doesn't appear to be needed" (but wouldn't hurt anythi= ng) Here are some of the complexities (and unknown factors): - We have Grover's algorithm (which is an algorithm that runs on a Quantum = Computer that supposedly does "key halving" of symmetric ciphers; that is, = it searches for an n bit key in 2*(n/2) time) - However, if we insert the assumption of bounded quantum circuit depth; th= at is, we insist that we get the result of the search quickly, say, within = 1000 years, then the attacker using Grover's algorithm needs to significant= ly more computation resources to search for a large key, that is, the level= of security is significantly higher then what "halve the key" would indica= te. With a conventional computer, we can perform parallel searches without= increasing the cost (total amount of computation performed); with Grover's= , performing the search in parallel cuts into the advantage that Grover's b= rings to the table. - How expensive is a multitarget comparison for a Quantum Computer (as oppo= sed to a conventional one, where it is cheap)? After all, the entire point= of this effort is to use a multitarget comparison to search against a larg= e number of targets at once. This is relevant because if it is of signific= ant cost, it would require more computational resources, which against, wou= ld effectively raise the security level achieved. I did glance at a simila= r scenario a while back; I came to the conclusion that a multitarget versio= n of Grover's would cut circa 10-12 bits from the security level (by search= ing against circa a million targets - increasing the targets beyond that st= arted to increase the cost most than just adding additional parallel search= ers); however this was a fairly informal study, and I never published it. - How costly (in terms of performance and expense) is a Quantum Gate (of va= rious different flavors) compared to conventional gates? This is a constan= t factor; however if it is large constant (e.g. a Quantum Gate is as expens= ive as one billion conventional gates), well, a factor of 2**30 really can'= t be ignored in practice. However, when I plug in plausible numbers to the above unknowns (especially= the last; for the previous, we do have some reasonable guesses), I still g= et that a quantum multicollision attack against AES-256 is still not feasib= le... From nobody Thu Jul 30 18:28:35 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88EBF3A0870 for ; Thu, 30 Jul 2020 18:28:33 -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, FREEMAIL_FROM=0.001, 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=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 q9yX3ZUeBMN6 for ; Thu, 30 Jul 2020 18:28:32 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 7E1B73A0849 for ; Thu, 30 Jul 2020 18:28:32 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id e64so30203289iof.12 for ; Thu, 30 Jul 2020 18:28:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=1NdA6KvWiibr/TZ+bwazG0J9Wf/UP+86WXLj9YrV4OU=; b=QiSMMfjR0VqksczU5b/mrodlrZWwY3WJSq+GgqBXBzmP2Fhd6erCg/izOSCQhecmbA F8aSmImNmkIms9CQ1iikm+WivTRiPVBpvWnIe9v2DlrBXxAKZX78gK/T1jYsV5vLwI0+ Up0v9wIgmUdhHrLsTfUSv6LpITqL1EX8615Y3+I9/mCYWTX1l9it6kr2vYNz9HddQ4Jn Dq6oEbF44K5RehggBj0NGS5ravAkJjC7vI7NHwM+KSTKXlNXoUGEpNfQoIU0HRaOJSa4 d4CnMdYouNLXdZ5dI4COE3iVeS1WEbfls0QIg7m3kxBmLsKrCiqkUZsi/pSJ8bYgjywH Zb7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1NdA6KvWiibr/TZ+bwazG0J9Wf/UP+86WXLj9YrV4OU=; b=NN97ds0pwVJVN0PKG91Mg6GW31j++zEg6aXj2lMOBksufpXGj3+AZpdAonlKhPWf2G lzj3w4L9tK7i6Y0D8pVm5BY3Fbk6j1DOLFo9hVUQcwF/2jMYWST8a9izU+Ky18Ky4Rm5 MkaEyCxl+N+MtBunPOy8I9x918fg8p7+TKQhniZ8plp7gqF75DKwhA6xYfAPhkaALorB dt6ffN/XwCTNZpTlFo5NUZRsK0pz7fkyJ5E+1CQ9avcABrl8yJrPihP3uuo4Csf4HXz8 VyGrbgbTiZWl+5tIkCVRVhNCtnjw6uHfmcEXqGY/Fe2kjA42gEJRbA1Au92hiBSBpMTo Vwmg== X-Gm-Message-State: AOAM531sMhWy8GcUr9A6o28R0sUJsR1nCfyyGAqSEo9ivVDfbEeIPhZj nMJiWu08VYHdMpkg6CE7lzT8C0ja X-Google-Smtp-Source: ABdhPJxyJwM185BueIhEzyIDr6OFrJPAWZB6ArLyREUGVuvTVrdzPpgiEPt770p7hKlsWHu66rGN3A== X-Received: by 2002:a5d:91d4:: with SMTP id k20mr1416017ior.9.1596158911591; Thu, 30 Jul 2020 18:28:31 -0700 (PDT) Received: from Wastelandia.local ([2601:401:500:1218:c87f:b793:60b:6d1e]) by smtp.gmail.com with ESMTPSA id k14sm3484046ion.17.2020.07.30.18.28.30 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Jul 2020 18:28:31 -0700 (PDT) From: William Allen Simpson To: ipsec@ietf.org References: <023E45E1-B1AA-4042-A8E3-DD7457235BC7@tu-ilmenau.de> <03c7c0d4-698e-bf07-e3af-aaa2eb81221f@gmail.com> Message-ID: <1f464ae1-2f38-51ff-e087-269d033fc4cd@gmail.com> Date: Thu, 30 Jul 2020 21:28:30 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <03c7c0d4-698e-bf07-e3af-aaa2eb81221f@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [IPsec] multiple windows need multiple SPIs 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, 31 Jul 2020 01:28:34 -0000 On 7/24/20 2:28 PM, William Allen Simpson wrote: > Therefore, I'd recommend that IPsec instead implement a block of related SPIs. > Each SPI should have its unique session-key as usual, but all would have the > same next protocol header and TCP/UDP port associated with the same flow. > > In the Photuris Extended Attributes internet-draft circa July 1997, we defined > the SPI-Block option.  Without the overhead of multiple negotiations, a single > exchange could generate a list of many related SPIs. > > You could send on several SPIs concurrently. Although there has been some pushback, have we agreed that instead of multiple windows (however defined), a more general solution is multiple SPIs? Who is going to write the SPI block/group extension for IKEv2? Would it be best to add to an existing draft already in the pipeline? From nobody Thu Jul 30 19:14:13 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 013013A0AFD for ; Thu, 30 Jul 2020 19:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 s8dDQCRb-6yI for ; Thu, 30 Jul 2020 19:13:59 -0700 (PDT) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 84C9B3A0AF5 for ; Thu, 30 Jul 2020 19:13:59 -0700 (PDT) Received: by mail-il1-x136.google.com with SMTP id t4so24169188iln.1 for ; Thu, 30 Jul 2020 19:13:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=+L8KuOjemHAIbRlMr6LvQn5L9JNs3j/4qb0iWHDthYM=; b=I/1aCm88mDbcYJpxmSKGEsHVZxTxXlS+nFcRGMGiXFqwALr+QxSPzR8dO/q58MRAib 2IxY//zpo2Twbc13J0pRWsCT3JMr4Secn8rEUtGSzfH8gM0ub2ySDHDo/YACrG0G9WXp pW+viMaBOqobVHApucTLjjub4Y7WjwdXWZuN9XIRamoLjIu34cnFatJnloaHHHPJ7Cyk uf8yfrpJEEj77DkCRpUXW4rvMYaBSaFLNtIg69pHMDPa5agy45wsmEwwuMyjuBs7ZV3W xtZPMr7IZfqFW/ulPOLuUl3yEJQryyHJVAzH8t26pVNhDgLj9hKiEAO3EP6lE/bF352Z Oolg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=+L8KuOjemHAIbRlMr6LvQn5L9JNs3j/4qb0iWHDthYM=; b=Cp8DcY1QJf110EoPWSwSyx88ivyJyUGPdRAbIw3o2G9qtxHsCMiSSCcXdKbyG9CjDx h9j4cfEt8igSkZ6Tj7x2dNGY9+0NjDJ490Ad2GuycAcl1ZonO2ZmZHXKpZRlsYUzaFTV YrScnrS2XY2Zxe15zQctF0A6HgEY7tS6f+fxpAFwa4qw0RwBV1AzNz25DAEXsW+0NMs3 PQHtyTptEyumESf+wk9lG2SMSkWnMLbidFiusGRxnWgoSz39Cg+9wkSkXwA6eHLBdZ7V csZMkDEDCoRkercdiUdXYsfrn7YZKowRetj9B5GKLO22qSRjQY3+PcZnUBIZk6xawONg C6NQ== X-Gm-Message-State: AOAM533/8wKa/2IKxrgWRXWw1cIbcswXs5sYdSzASVcxaM6+i7e6qAkG 7XXC7QyNFBp2Wt45sy8rN7nsEcWz X-Google-Smtp-Source: ABdhPJxxANamPghg4c3+FN6k1t51oYhNb8lWATvpLCQKd/0oa4CWs8IrA9HVc/8FhObPuHxEv96xpg== X-Received: by 2002:a05:6e02:1203:: with SMTP id a3mr1497903ilq.85.1596161638707; Thu, 30 Jul 2020 19:13:58 -0700 (PDT) Received: from Wastelandia.local ([2601:401:500:1218:a130:72c0:643c:1dcc]) by smtp.gmail.com with ESMTPSA id e1sm3851779ilr.23.2020.07.30.19.13.57 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Jul 2020 19:13:58 -0700 (PDT) To: ipsec@ietf.org From: William Allen Simpson Message-ID: <5484040d-3b40-d94a-634e-c182c9165634@gmail.com> Date: Thu, 30 Jul 2020 22:13:57 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [IPsec] leading versus trailing ICV 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, 31 Jul 2020 02:14:01 -0000 The comments thus far seem to be mixed. This is a perennial topic. We spent much time on it in PIPE/SIPP/IPv6. We agreed on leading for AH and trailing for ESP. When I wrote the KA9Q NOS code implementing Van Jacobson's packet buffers that eventually was ported to Linux by Alan Cox, the code knew it had an incoming Ethernet or PPP frame, and offset the head on a 16-bit or 32-bit boundary as needed with enough space at the tail for all trailing bytes. The IP header was always on a 64-bit boundary. Hopefully, that code is still present. In modern CPUs, there's always an issue with cache lines. But for a parallel implementation, it really isn't going to matter. The CPU that finishes last and needs to check the ICV isn't particularly likely to be the CPU that processed the initial header anyway. As a matter of historical record, this was also a long debate for TCP. The default is leading, and there is a TCP option for trailing checksum. Might it be a non-default option negotiated per SPI? From nobody Fri Jul 31 01:33:18 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36EC63A10EE for ; Fri, 31 Jul 2020 01:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsB6QKPst7jr for ; Fri, 31 Jul 2020 01:33:04 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [62.96.220.36]) (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 479913A10F2 for ; Fri, 31 Jul 2020 01:33:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 14EBC205FA; Fri, 31 Jul 2020 10:33:01 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYB15xbNP7jj; Fri, 31 Jul 2020 10:33:00 +0200 (CEST) Received: from mail-essen-02.secunet.de (mail-essen-02.secunet.de [10.53.40.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by a.mx.secunet.com (Postfix) with ESMTPS id 9AB8820573; Fri, 31 Jul 2020 10:33:00 +0200 (CEST) Received: from mbx-essen-01.secunet.de (10.53.40.197) by mail-essen-02.secunet.de (10.53.40.205) with Microsoft SMTP Server (TLS) id 14.3.487.0; Fri, 31 Jul 2020 10:33:00 +0200 Received: from gauss2.secunet.de (10.182.7.193) by mbx-essen-01.secunet.de (10.53.40.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Fri, 31 Jul 2020 10:33:00 +0200 Received: by gauss2.secunet.de (Postfix, from userid 1000) id BBF0E3180676; Fri, 31 Jul 2020 10:32:59 +0200 (CEST) Date: Fri, 31 Jul 2020 10:32:59 +0200 From: Steffen Klassert To: William Allen Simpson CC: Message-ID: <20200731083259.GG20687@gauss3.secunet.de> References: <5484040d-3b40-d94a-634e-c182c9165634@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <5484040d-3b40-d94a-634e-c182c9165634@gmail.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-ClientProxiedBy: cas-essen-01.secunet.de (10.53.40.201) To mbx-essen-01.secunet.de (10.53.40.197) X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Archived-At: Subject: Re: [IPsec] leading versus trailing ICV 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, 31 Jul 2020 08:33:10 -0000 On Thu, Jul 30, 2020 at 10:13:57PM -0400, William Allen Simpson wrote: > The comments thus far seem to be mixed. This is a perennial topic. > We spent much time on it in PIPE/SIPP/IPv6. > > We agreed on leading for AH and trailing for ESP. > > When I wrote the KA9Q NOS code implementing Van Jacobson's packet > buffers that eventually was ported to Linux by Alan Cox, the code knew > it had an incoming Ethernet or PPP frame, and offset the head on a > 16-bit or 32-bit boundary as needed with enough space at the tail for > all trailing bytes. On Linux, it dependes a bit on the NIC driver how that is handled. The default headroom is max(32 bytes, L1_CACHE_BYTES), space for a trailer is not reserved. > The IP header was always on a 64-bit boundary. > Hopefully, that code is still present. The default alignment of the IP header is on a 16 byte boundary. It looks like this: NET_IP_ALIGN(2) + ethernet_header(14) + IP_header(20/40) + L4_header(8) Architectures can change the 2 byte NET_IP_ALIGN if they prefer DMA alignment over IP alignment. > In modern CPUs, there's always an issue with cache lines. But for a > parallel implementation, it really isn't going to matter. The CPU > that finishes last and needs to check the ICV isn't particularly > likely to be the CPU that processed the initial header anyway. While that would be possible for some algorithms, I've never seen that a single cipher request is handled by multiple CPUs. I guess that would lead to cacheline bouncing, and for GCM an atomic synchronization of the counter would be needed. Usually parallelization is achieved by using AVX registers/instructions where multiple cipher blocks can be handled simultaneously with a single instruction. So it might make sense to have the ICV at the end because it is likely cache hot when needed. From nobody Fri Jul 31 01:37:22 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF71C3A10EE for ; Fri, 31 Jul 2020 01:37:20 -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 Dt3PjcupXGKA for ; Fri, 31 Jul 2020 01:37:19 -0700 (PDT) Received: from smail.rz.tu-ilmenau.de (smail.rz.tu-ilmenau.de [141.24.186.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B7793A0F88 for ; Fri, 31 Jul 2020 01:37:18 -0700 (PDT) Received: from [192.168.2.166] (unknown [93.252.45.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smail.rz.tu-ilmenau.de (Postfix) with ESMTPSA id E7A22580060; Fri, 31 Jul 2020 10:37:15 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_566AEDC6-A0B8-4134-9277-44A68DD1936D"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Michael Rossberg In-Reply-To: <1f464ae1-2f38-51ff-e087-269d033fc4cd@gmail.com> Date: Fri, 31 Jul 2020 10:37:05 +0200 Cc: ipsec@ietf.org Message-Id: <703EBF8C-4A94-4329-B720-369B9180EADA@tu-ilmenau.de> References: <023E45E1-B1AA-4042-A8E3-DD7457235BC7@tu-ilmenau.de> <03c7c0d4-698e-bf07-e3af-aaa2eb81221f@gmail.com> <1f464ae1-2f38-51ff-e087-269d033fc4cd@gmail.com> To: William Allen Simpson X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [IPsec] multiple windows need multiple SPIs 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, 31 Jul 2020 08:37:21 -0000 --Apple-Mail=_566AEDC6-A0B8-4134-9277-44A68DD1936D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 7/24/20 2:28 PM, William Allen Simpson wrote: >> Therefore, I'd recommend that IPsec instead implement a block of = related SPIs. >> Each SPI should have its unique session-key as usual, but all would = have the >> same next protocol header and TCP/UDP port associated with the same = flow. >> In the Photuris Extended Attributes internet-draft circa July 1997, = we defined >> the SPI-Block option. Without the overhead of multiple negotiations, = a single >> exchange could generate a list of many related SPIs. >> You could send on several SPIs concurrently. >=20 > Although there has been some pushback, have we agreed that instead of = multiple > windows (however defined), a more general solution is multiple SPIs? Sorry, I have not caught up with answering all mails yet. For each of the cases multicast, multicore & QoS there have been a lot = of people arguing for such a solution. However, I still see the argument, that enabling = all of these features will lead to a combinatorial explosion of SAs, which are brought up = proactively, even though perhaps never used. Somehow associated SAs would perhaps allow us to derive/install a key = locally on demand. However, due to the combinatorial explosion, these blocks of SAs may = easily become pretty large, ie. with a reservation for multicast senders and QoS groups SPIs = may be a little short. > Who is going to write the SPI block/group extension for IKEv2? I am afraid there are more things affected with such a way to go, e.g. = g-ike. There are still other things uncovered: Explicit 64 bit sequence = numbers, implicit IVs for group communication, the whole trailer discussion. All in all these changes make raise the complexity even further, a thing = we tried to reduce by unifying things for the multi/unicast case. Allowing people to use = the same dataplane configuration to encap L2 frames. > Would it be best to add to an existing draft already in the pipeline? I would volunteer to perhaps write things together in a longer = argumentation over this fall. --Apple-Mail=_566AEDC6-A0B8-4134-9277-44A68DD1936D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEE/ZtCXI3ladZ37VLCzADDFAM3dskFAl8j2DEACgkQzADDFAM3 dskGPA//f8Gz+NvglBkYDF7FGxT/5OOus25UC0d613gws3XEzd06XCvHKRFNRF0c LamwhTMGw058xqoualfDNuprOHX+tCsr4ff9se6ybqYN/Awjo9emVZiPZF+pCwZR 8QKZgaWaOsAohMgUgBVMSMhLXeWYyON3cnAiFjGzbZc4Wqk9nriNr2Dt2dfzVvwR 2xjvIIfgRtRXSPVf8gwQmw5rjDGOs0n+lB32ggSl+1qgIFU1q9dk33wsyvIQh1yh dn+aAbtneQNSFaq1FMKT1AFWv4TlskMT0DXXU/cnUut3RbIG522bhYphAqgDpdhF R7v0wdskQWYHjeHhcAZclw8DX2EaZDlAqG+rEYfnlQzTf3HVfh/rshxyG4PFLU/I PT6tRZ7qK0+ksRM/95osoyUZ6Ko8AIv4d1QP4vOo9A01+wcZpgQETD1+1PCNqBAM TBIPcqYSYxhuN9hHn1Vuy5BcoKq855gmT7fFZrDdBrrGQkMLUIo+/P++fpxTWYsQ yhtg98EMoMufejktxdaQ3WvDU9kjWzNRhGfNjRKHEnRMy4zxpiZPLbCZvF9SrHLZ mtkrOT4HrBbkQYt3rSksQkEOTqaEAO7eyDTOAmOCZ8ZrkQ6xveRisxcdkr41VzmY 3LJy7rSxRtRlyw3WBE+iVbA27mN1RIVYsRH81b0IIq05FKtrBXs= =Wi/t -----END PGP SIGNATURE----- --Apple-Mail=_566AEDC6-A0B8-4134-9277-44A68DD1936D-- From nobody Fri Jul 31 01:44:55 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADBE3A1056 for ; Fri, 31 Jul 2020 01:44:53 -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 5VF134WzS2a4 for ; Fri, 31 Jul 2020 01:44:51 -0700 (PDT) Received: from smail.rz.tu-ilmenau.de (smail.rz.tu-ilmenau.de [141.24.186.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12ABB3A10F0 for ; Fri, 31 Jul 2020 01:44:50 -0700 (PDT) Received: from [192.168.2.166] (unknown [93.252.45.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smail.rz.tu-ilmenau.de (Postfix) with ESMTPSA id B0CC1580060; Fri, 31 Jul 2020 10:44:48 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_DA71B286-B0CA-4202-AD49-D54880C62BB1"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Michael Rossberg In-Reply-To: <20200731083259.GG20687@gauss3.secunet.de> Date: Fri, 31 Jul 2020 10:44:48 +0200 Cc: William Allen Simpson , ipsec@ietf.org Message-Id: References: <5484040d-3b40-d94a-634e-c182c9165634@gmail.com> <20200731083259.GG20687@gauss3.secunet.de> To: Steffen Klassert X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [IPsec] leading versus trailing ICV 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, 31 Jul 2020 08:44:54 -0000 --Apple-Mail=_DA71B286-B0CA-4202-AD49-D54880C62BB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >=20 >> In modern CPUs, there's always an issue with cache lines. But for a >> parallel implementation, it really isn't going to matter. The CPU >> that finishes last and needs to check the ICV isn't particularly >> likely to be the CPU that processed the initial header anyway. >=20 > While that would be possible for some algorithms, I've never seen that > a single cipher request is handled by multiple CPUs. I guess that > would lead to cacheline bouncing, and for GCM an atomic = synchronization > of the counter would be needed. >=20 > Usually parallelization is achieved by using AVX = registers/instructions > where multiple cipher blocks can be handled simultaneously with a = single > instruction. >=20 > So it might make sense to have the ICV at the end because it is > likely cache hot when needed. This is not what we have seen in measurements. Caches are usually much larger than a single packet. This is especially true for small packets, = where current software en/decrypters have performance issues with. Since the = packet is passed further through the stack the header needs to be "hot=E2=80=9D = anyways. However, what we have seen: appending at front and end leads to = situations where a new cache line is required at both ends. More cumbersome in my option is the whole zero-copy/dealing with segment lists issue, when having to add things in front and at the end. --Apple-Mail=_DA71B286-B0CA-4202-AD49-D54880C62BB1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEE/ZtCXI3ladZ37VLCzADDFAM3dskFAl8j2gAACgkQzADDFAM3 dskc3w//beJptrkdJtfT+o5M0kdnhgzSW5fGpb6mviMtF2MB5Ma0yPsDNUe0+R7V CWVcputajpKOINooo2AoyOekUuui8AF1VVUUwk2TNIIUZZkyl2a7z+DMROijYUhn G3BUsea0E2bvjjNvNQHKX1QnZuuvn1CleeDJ9gcjUuIFmpxbks7E/2lluD1qGebO 2J3EAYRldJ0DAWLpet4eRtymnF/Oo+2SJUyBrQwG2Ow2Xh3E0u7WCKPO+ZR3gMRY lE3NCp+FsxbYz9INwE4xrgmCeHsz8jJr/SUvVaeRHHRSpMpPpFj6Ts24zmDZuyYE ioJ4rJ6PqNT8fXvexoq+gHvKfTk9xbdBb/x8b2QkOneopeAFcsWWHjwDxQfAGPrb PNrl2Xf0Os4b65O8Q0Z5QC9uEdAt3UddSwADXF8WVf6ZLc5qe1atXaR+JguWPtM0 U2+wkfuYd+4H4XEHS3roTSIDCAtClote91M1cBVni8kcBlViAmy9D65dwq8Iv1Yl yaSQc2RhKt4JxLUMLBppi5Fqiy0qDZTQ7YpasD34AWDGtRO/7QJAg3tZAzEI3V0u kiciNVlVJuiQJ7EAYLg/CtwG0zAwbXNIQGJtIs0Fi/A91h3mxB+Dm/BF+CNCXK4x bAU1dl+/418AI6ic0/mf5cxsZPX6DpFVrE0+CgEJ389yAu6zBJE= =0f9Q -----END PGP SIGNATURE----- --Apple-Mail=_DA71B286-B0CA-4202-AD49-D54880C62BB1-- From nobody Fri Jul 31 17:23:56 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A538E3A0DB8 for ; Fri, 31 Jul 2020 17:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 gP1PF9tThl92 for ; Fri, 31 Jul 2020 17:23:53 -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 ACB153A0DB7 for ; Fri, 31 Jul 2020 17:23:52 -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 0710NkE0012141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 31 Jul 2020 20:23:48 -0400 Date: Fri, 31 Jul 2020 17:23:46 -0700 From: Benjamin Kaduk To: mohamed.boucadair@orange.com Cc: Yoav Nir , Tero Kivinen , "ipsec@ietf.org" Message-ID: <20200801002346.GV92412@kduck.mit.edu> References: <24352.9444.775247.214537@fireball.acr.fi> <16927_1596001099_5F210B4B_16927_206_1_787AE7BB302AE849A7480A190F8B933031506915@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <16927_1596001099_5F210B4B_16927_206_1_787AE7BB302AE849A7480A190F8B933031506915@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [IPsec] Preliminary minutes from the IETF 108 IPsecME WG Meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2020 00:23:55 -0000 Hi Med, Yoav, all, On Wed, Jul 29, 2020 at 05:38:17AM +0000, mohamed.boucadair@orange.com wrote: > Hi Yoav, Ben, all, > > == > Ben (AD): (missed first point Belongs in ADD?) Slide with attribute format, for DoH, need to provide URI template FWIW, the first point was not quite "belongs in ADD" but more "ADD is doing a lot of similar-ish stuff; let's stay informed of what's going on, in both directions". > Valery: Presentation also requested in ADD, but didn't have room in agenda. Re: URI, will be covered in DoH clarifications (?) > == > > Valery was referring to https://tools.ietf.org/html/draft-btw-add-rfc8484-clarification-02#section-6.1 where we define a well-known uri that will be used to retrieve the uri templates directly from the discovered Encrypted server. We that approach, we don't need to supply the URI template in the IKE attribute. Ah, thanks; I hadn't encountered that one yet. -Ben > Cheers, > Med > > De : IPsec [mailto:ipsec-bounces@ietf.org] De la part de Yoav Nir > Envoyé : mardi 28 juillet 2020 22:22 > À : Tero Kivinen > Cc : ipsec@ietf.org > Objet : Re: [IPsec] Preliminary minutes from the IETF 108 IPsecME WG Meeting > > Hi. > > I uploaded a PDF version to the meeting materials. Also added a list of action items for the chairs. Comments are welcome on that part as well. > > https://www.ietf.org/proceedings/108/minutes/minutes-108-ipsecme-00 > > Yoav > > > On 28 Jul 2020, at 16:15, Tero Kivinen > wrote: > > Here is preliminary minues from the IETF 108 IPsecME WG meeting. I > copied some discussion about the proposed changes to ESP from Jabber > to here, as I think it was important to record those even when we did > not have time to have comments during the meeting. > > If you have any comments, please send them to me as soon as possible. > ---------------------------------------------------------------------- > # IPsecME IETF 108 > > Time: Tuesday, 28-Jul-2020, at 11:00-12:40 UTC > > ## Agenda: > * 11:00-11:05 - Note Well, technical difficulties and agenda bashing > * 11:05-11:10 - Document status (chairs) > * 11:10-11:25 - draft-smyslov-ipsecme-rfc8229bis (Valery/Tommy) > * 11:25-11:35 - draft-btw-add-ipsecme-ike-00 (Valery) > * 11:35-11:45 - draft-smyslov-ipsecme-ikev2-auth-announce (Valery) > * 11:45-12:00 - Proposed improvements to ESP (Michael Rossberg) > * 12:00-12:15 - IPTFS (Christian Hopps) > * 12:15-12:30 - YANG model for IPTFS (Christian Hopps) > * 12:30-12:40 - AOB + Open Mic > > ### Note Well, technical difficulties and agenda bashing > *Chairs* (5min) > > No Edits > > ### Document status > *chairs* (5min) > > *-implicit-Iv published as RFC8750 > *-qr-ikev2 published as RFC8784 > > *-ipv6-ipv4-codes publication requested > > ### draft-smyslov-ipsecme-rfc8229bis (TCP encap of IKE/IPsec) > *Valery/Tommy* (15min) > > Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-rfc8229bis-00 > > Paul Wouters: What are the kernel implications? And does this allow for smaller IPsec/ESP Packets? > Valery: Text is a bit short, TCP stream packets will have same class > Paul: What Interop testing has been done? > Valery: Tested with Apple, Cisco, libreswan > > Piannissimo Hum for who has read the draft > > Paul: Good idea to adopt, found issues that would be good to incorporate in draft > > Yoav: Will take to list if we need an update to 8229 and if this is the right starting point. > > ### draft-btw-add-ipsecme-ike-00 (IKEv2 config for Encrypted DNS) > *Valery* (10min) > > Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-ikev2-configuration-for-encrypted-dns-00 > > Paul: What to do outside of VPN tunnel seems out of scope? (regarding Scope bit) > > Valery: Still an interesting subject > > Ben (AD): (missed first point Belongs in ADD?) Slide with attribute format, for DoH, need to provide URI template > > Valery: Presentation also requested in ADD, but didn't have room in agenda. Re: URI, will be covered in DoH clarifications (?) > > Ben: When DoQ arrives may need additional work > > Tero: Add configuration attributes, less internal strucutre, more higher level structure > > Yoav (participant): Missing motivation from draft Moving towards encrypted world, don't want to force people to keep insecure DNS just for legacy IKEv2 server > > Valery: That is one of the motivations; users won't see this, but it is useful. > > Tirumaleswar Reddy: URL can be discovered another way > > Benedict Wong: My understanding is that in some cases we need a hostname to do validation of the DoT server > > Tirumaleswar: This only supports PKI-based verification, so we can verify based on sent certificate. > > Yoav: Calling for adoption? > > Valery: ADD Primary target for adoption, ipsecme is just informational, if there is interest it could persist in this WG, but not yet. > > Tirumaleswar: Couple more revisions necessary, extension to IKE, want to make sure both working groups are aware of work > > Ben (AD): If ipsecme was concerned by the work, or on the other hand thinks it makes sense, it's good information for ADD to have > > ### draft-smyslov-ipsecme-ikev2-auth-announce > *Valery* (10min) > > Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-announcing-supported-authentication-methods-in-ikev2-00 > > Paul: Good idea, unclear where complexity might be, in the past migration between methods (null -> something else) needed a ppk hack - sending two auth payloads > > Tero (participant): Could have one part negotiate the algorithm, and the second part to negotiate the algorithm ids for CAs in the certreq > > Yoav: will take a call for adoption to the list > > ### Proposed improvements to ESP > *Michael Rossberg* (15min) > > Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-proposed-improvements-to-esp-01 > > Yoav (?): Discussion happening on list and in jabber. Informational would be wrong, changes packet on wire, so experimental or standards track if anything > > Summary of questions and comments from the jabber: > > * Yoav: Some firewalls would be very upset about this packet format, because it looks like every packet is retransmission. > * Paul: so flip sender/window id with sequence number > * Chopps: andeven put the higher order after lower order so stays exactly the same as before > * Scott Fluhrer: In addition, each sending id/window id has its own replay window, does that mean that the receiver needs to track 4 billion antireplay windows? > * Scott: Also, it wouldn't be secure with CBC > * Paul: It drops all non-AEAD, which we should do anyways > * Scott: You also lose the multitarget protection with GCM by not including the 32 bits of key-derived nonce > * chopps: The sender id is really a mcast thing, so it reduces to 64k > * Scott: Does the receiver need to track a antireplay window for each multicast sender? > * Yaov: Yes > * Scott: I can't see how that can work on a decryptor that can't dynamically allocate memory > * Bob Moskowitz: Would need a change to robust header compression so that smaller seq# for constrained links? > * Valery: This proposal lacks enough generality to replace ESP - it considers very small set of ciphers and use cases > * Paul: and we might as well throw in a discussion of implicit IV if we are updating ESP to v4 > * Yoav: @Valery: doesn't it use all the ciphers that people care about now? Consider that TLS 1.3 has about two ciphers (plus another 1 for IOT). > * Valery: In addition, many things it aims for can be achieved using ESP. Even replay protection for multicast (with some limitations). > * Steffen Klassert: Get rid of the trailer would be nice from implementation point of view > * Valery: @yoav, No, it doesn't work with CBC at all. Moreover, if IV is somehow structured, it won't work too > * Yoav: TLS 1.3 doesn't support CBC either. > * Valery: I understand, but what if tomorrow a new cipher mode appear that is superior to GCM and will require some special form of IV? The problem is that this design requires IV to be in a particular form. If cipher requires other form, it'll fail > > Tero: Not in charter, this is a big change. See if it is a good idea first before taking to much time discussing and writing > > ### IPTFS -- [draft-ietf-ipsecme-iptfs-01](https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-01) > *Christian Hopps* (15min) > > Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-ip-traffic-flow-security-00 > > Yoav: Hasn't gotten much review, WGLC is one way, but don't know if it is the best way. Requesting transport area early may be a good way too. > > Tero: Might be hard to get another protocol number. > > Lou: Getting a protocol number shouldn't be a big deal; many can be deprecated. > > Ben: Please fill out the official early-allocation form request. > > Agreed on sending this out for transport area early review. > > ### YANG model for IPTFS -- [draft-fedyk-ipsecme-yang-iptfs-00](https://tools.ietf.org/html/draft-fedyk-ipsecme-yang-iptfs-00) > *Christian Hopps* (15min) > > Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-yang-model-for-ip-traffic-flow-security-00 > > Tero: SDN YANG models generally work in two mode, either IKE-less, where it configures IPsec SAs, or in IKE mode where it does not touch IPsec SAs, as IKE configures them, so they wanted to keep the configuration clear which parts they are configuring. > > Christian: Also operational state, even if not configured via YANG > > Tero: If we could consolidate on a single YANG model, that would be ideal (such as I2NFS) > > Yoav: Per chat, would benefit from a YANG Dr. review > > Lou: Would benefit from another review, per datatracker, latest draft needs another review. > > ### AOB + Open Mic > *all* (10min) > > Paul: Labeled IPsec still in review. Graveyard draft still in limbo > > Tero: Take to list; a few of these can go to WGLC, but should check with AD first. > > Tero: I think we need to have interm meeting about the ESP. We cut the discussion out from here, as it would have taken the rest of the time, but we should have separate interm just for it. > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. >