From nobody Sat Aug 1 03:47: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 DB51F3A0D3C for ; Sat, 1 Aug 2020 03:47:42 -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 qZGppCCAQS0p for ; Sat, 1 Aug 2020 03:47:41 -0700 (PDT) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 95ED13A0D3B for ; Sat, 1 Aug 2020 03:47:41 -0700 (PDT) Received: by mail-il1-x134.google.com with SMTP id s21so27386066ilk.5 for ; Sat, 01 Aug 2020 03:47:41 -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=M4PGrUYVtl57VPmmopKfVUjHQpH78F58nrjDdX3m1w4=; b=CfILMPkqum7L1F9uwvTmOntEZALzXYqiB94hLt+VInoh1drEliWXDX2O3YXbJ9NMM6 weoEEAJE1CpZPxl1wKJY37jQVgvO2ja04iVxCPfDTz+pochhFIKbBB4UxoST6JUMLz73 yY2FJT/Ka8lZzAhGRZLgHTo6FsykgHLs+QenguzyHzUMehvaNah8oTmXl54CpcpxxNdZ xaRmoJ1gsNTxwSHugVaDHYmcCDIH+NZlVKlyMjFwiNf9WBPa9J4B+FfNW8/y2JGJZKVk 2XAxUeCoVH8S9g+5NQ6xNK76+I0op5Y73t4aHxE7NV923BAXCOKyW8apIrblyz7+UoOJ +uIQ== 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=M4PGrUYVtl57VPmmopKfVUjHQpH78F58nrjDdX3m1w4=; b=cX7vEsj1VuvQ0hiuV7y9JzXaNKrKiTPlvKn7TUlaJvq6HR4MxzORMYCt428D7o+O2O oJkvu3HYTelVnZW5M1HO9gHfpzisgPbgrVFdbvs/6MB1UVMnqHFpkOS7EFHMwwCR+hcI FuCEapRRIah62WdGP/qUi7XsjbFFzCcNsM/dXaPHsgSXDg8uiQXpB9mBV6w+y1v/1x7H a4ZCVVOyjjdNnOPbfMshgVSMheyZ95kMTy+f/Fq7nsMjz1Ep7RqB5Ds491+nypfMmqXV +PeM0RO1Q+i1lxR1nXArogTQuM7K9jo8ECAFMGwCcLQSxW74nba9RRiBx/JFO/90oxGt PCCg== X-Gm-Message-State: AOAM532P524/6M43vaY8YZ+6ilPrE2XT/Je19qOniBlHv1MCTlhlnHfl jxhu0f1APHI46Ru8S+WF4DGh6qVk X-Google-Smtp-Source: ABdhPJxPB0BJo7QyfRBteBZodV2qWWq+seuw8pZ0y9O8qGlugD3clCQ1rZ697xsTz8eSXed3fNX4/Q== X-Received: by 2002:a05:6e02:f85:: with SMTP id v5mr7887182ilo.31.1596278860732; Sat, 01 Aug 2020 03:47:40 -0700 (PDT) Received: from Wastelandia.local ([2601:401:500:1218:c95d:92af:8a74:bfd0]) by smtp.gmail.com with ESMTPSA id b2sm6726298ilf.0.2020.08.01.03.47.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 01 Aug 2020 03:47:40 -0700 (PDT) To: Steffen Klassert Cc: ipsec@ietf.org References: <5484040d-3b40-d94a-634e-c182c9165634@gmail.com> <20200731083259.GG20687@gauss3.secunet.de> From: William Allen Simpson Message-ID: <97778198-87b3-e27e-6da9-b3ea83f62b29@gmail.com> Date: Sat, 1 Aug 2020 06:47:39 -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: <20200731083259.GG20687@gauss3.secunet.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Sat, 01 Aug 2020 10:47:43 -0000 On 7/31/20 4:32 AM, Steffen Klassert wrote: > Architectures can change the 2 byte NET_IP_ALIGN if they prefer > DMA alignment over IP alignment. > As I mentioned in an earlier email, my most recent RFC work is RDMA. > 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. > Currently, one CPU cannot keep up with encryption/decryption of RDMA at merely 10 Gbps, let alone 100 Gbps. This changes over time. In the beginning, we were struggling to keep up with 56 Kbps, and upgrading the backbone from 1.5 Mbps T1 to 54 Mbps T3. Then for while, CPUs outran network speeds. Now we're back again to link speeds outpacing CPUs. As I'd written PPP over SONET/SDH in 1992 (RFC 1619 published in 1994), when designing ESP circa 1992-1993 we were cognizant that link speeds would increase. After all, I'd specified the minimum speed as 156 Mbps, and up to 2.5 Gbps. There were only a few places in the world that could support those speeds, but we anticipated them. Photuris was able to run on the Intel 186 (admittedly, it took about 3 seconds), but Rivest estimated it would handle DoS attacks up to 4 Tbps. > Usually parallelization is achieved by using AVX registers/instructions > where multiple cipher blocks can be handled simultaneously with a single > instruction. > I'm also personally less interested in AES-GCM than ChaCha20-Poly1305. We really need to design for at least 2 algorithms. In the beginning, we worried about designing for unknown future algorithms. That's why it had very flexible transforms. > So it might make sense to have the ICV at the end because it is > likely cache hot when needed. > But after removing padding for these stream algorithms, then the ICV is very likely not aligned. For zero-copy RDMA, it is rather inconvenient. And the IP header cache lines are likely still hot. Anyway, that's why I'd like to consider at least a negotiated option -- as long as it's possible to implement efficiently in Linux and others. We need to hear from more implementers. From nobody Sat Aug 1 04:54:42 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 BF5DE3A0DEC for ; Sat, 1 Aug 2020 04:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 OU9mXNnJMUDp for ; Sat, 1 Aug 2020 04:54:38 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 0844E3A091B for ; Sat, 1 Aug 2020 04:54:37 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id d18so34209579ion.0 for ; Sat, 01 Aug 2020 04:54:37 -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=WLBu4ZtwVASkFKFpV1Wjn0GIcjZxN6aJnqsGAjueKYg=; b=L8QWqHWL+2SWh8mSY9b3BKKxISJ3LCIUDIaRHOn6imaU+cARceId2MNKNjPKf5qpfv gdqKKzXtwuyxP1kXHmofS2v5syMLGApPK55RD95XxFAT1x25pKgywnrsydXbuei6nsvn mfoNwOn6D8+Gr5UIpWRA5qZiBKquk9soERoqguWMfVNGg5Ke3tiZFX0cr0eDFyb1SqZM fKzKjzo+jaNGiGrzFygMc1rJfHATePtF+ENWr/EthJLdgsYMq57YPuRycXDfEdOZhYvv c72UOLCejTMtaXDtgIvzSN8JWoTW50u9v5P5xBTIz1XeoJ8BPBRNk2RdQbbbXRQ3d0L3 LDow== 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=WLBu4ZtwVASkFKFpV1Wjn0GIcjZxN6aJnqsGAjueKYg=; b=ffKBmUoDHca9oirGaX2JHNrSmiV3jR3Nryp5rVm3/qJ8jeuQDMCP949QdehZ+RmiVP Yq455ZVWBu1FSqONL/F84gZlTxsbMqThesBCpFbOTKzNE0CzWc/AmUQcwvUKzVJWRRjb IlOrC3l319oKJv43AWqIufeiEHdWujwpYw1HQJN9mteutzKj+JzZUO4AqC3mz+dsH76D L+OC6ZH1MjCBh9dBX/AR84J6mdj5gqGousI4ke0giFoD0H2AwIddcXeWxdDkBqCEt+Fr n2JH/CNOmHzCRDiJ2R/CWpoLSzQRDeybV4/1CAxu1TCfGN06EdhNfl/opa8M6ulCQRPE Zpuw== X-Gm-Message-State: AOAM533faqQq8diSl2+vyeoU4M45QXQvbYBTtRWuHA8c9GZbSerjF4AA Z5K9EOczyTPQaxvoH4BfYDETag2o X-Google-Smtp-Source: ABdhPJwdTgAqQHf/hU0Imf/M3XtdDLcOo79JxQGiIfUpwvBfZGk0UmRP+YUgCWbvPrBlNoCiaz6rRA== X-Received: by 2002:a02:b90b:: with SMTP id v11mr10323117jan.111.1596282876733; Sat, 01 Aug 2020 04:54:36 -0700 (PDT) Received: from Wastelandia.local ([2601:401:500:1218:c95d:92af:8a74:bfd0]) by smtp.gmail.com with ESMTPSA id g13sm6776233ilq.18.2020.08.01.04.54.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 01 Aug 2020 04:54:36 -0700 (PDT) To: Michael Rossberg Cc: ipsec@ietf.org References: <023E45E1-B1AA-4042-A8E3-DD7457235BC7@tu-ilmenau.de> <03c7c0d4-698e-bf07-e3af-aaa2eb81221f@gmail.com> <1f464ae1-2f38-51ff-e087-269d033fc4cd@gmail.com> <703EBF8C-4A94-4329-B720-369B9180EADA@tu-ilmenau.de> From: William Allen Simpson Message-ID: <7e136b99-8a41-a2b8-caf3-100102407a2c@gmail.com> Date: Sat, 1 Aug 2020 07:54:34 -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: <703EBF8C-4A94-4329-B720-369B9180EADA@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: Sat, 01 Aug 2020 11:54:40 -0000 On 7/31/20 4:37 AM, Michael Rossberg wrote: > > Somehow associated SAs would perhaps allow us to derive/install a key locally on demand. Correct. In the original IPsec design, as we had specified that there could be multiple SPIs per SA, the definition of SA was broader than later editors. > 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. > Wow, what architecture are you implementing? After all, 2^32 SPIs by 2^32 packets per SPI are more than the estimated number of silicon atoms! When I originally designed PIPE and reserved v6, that initial draft eliminated the IP ToS field. I've never seen the need, and believe that history has validated my view. Since then, "integrated services" and "differentiated services" and other efforts have long been marketing points to extract money from naive customers, but have had little practical effect. As some folks know, once upon a time I founded one of the first ISPs in 1994. In more than a decade, I'd never had a customer who needed QoS. CoDel did far more for active queue management than QoS. (I was involved in the CeroWRT bufferbloat project, too.) IMnsHO, those who want to shoot themselves in the foot with QoS deserve the complexity and overhead. Still, I've no idea how you'd run out of SPIs. From nobody Mon Aug 3 01:18:12 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9863A0C77 for ; Mon, 3 Aug 2020 01:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[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 FjGSaWv9XLQO for ; Mon, 3 Aug 2020 01:18: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 ABE0D3A0C76 for ; Mon, 3 Aug 2020 01:18:07 -0700 (PDT) Received: from [192.168.2.135] (unknown [91.6.103.98]) (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 E7402580061; Mon, 3 Aug 2020 10:18:03 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_C3184BB0-DE5D-4FD4-9E2A-4FA56650560B"; 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: <7e136b99-8a41-a2b8-caf3-100102407a2c@gmail.com> Date: Mon, 3 Aug 2020 10:17:38 +0200 Cc: ipsec@ietf.org Message-Id: <91BA04C7-D68D-473B-A0DE-0E8DA19B7B53@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> <703EBF8C-4A94-4329-B720-369B9180EADA@tu-ilmenau.de> <7e136b99-8a41-a2b8-caf3-100102407a2c@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: Mon, 03 Aug 2020 08:18:10 -0000 --Apple-Mail=_C3184BB0-DE5D-4FD4-9E2A-4FA56650560B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >> 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. >=20 > Wow, what architecture are you implementing? After all, 2^32 SPIs by = 2^32 > packets per SPI are more than the estimated number of silicon atoms! >=20 > When I originally designed PIPE and reserved v6, that initial draft > eliminated the IP ToS field. I've never seen the need, and believe = that > history has validated my view. Since then, "integrated services" and > "differentiated services" and other efforts have long been marketing = points > to extract money from naive customers, but have had little practical = effect. >=20 > As some folks know, once upon a time I founded one of the first ISPs = in 1994. > In more than a decade, I'd never had a customer who needed QoS. >=20 > CoDel did far more for active queue management than QoS. (I was = involved in > the CeroWRT bufferbloat project, too.) >=20 > IMnsHO, those who want to shoot themselves in the foot with QoS = deserve the > complexity and overhead. >=20 > Still, I've no idea how you'd run out of SPIs. Unfortunately I develop systems for a customer who uses DS for some = (maybe non-technical) reason. The issue I am struggling with: If there are multiple =E2=80=9Creasons=E2=80= =9D to allocate blocks of SAs we=E2=80=99ll have a lot of unused SPI space. Coming back to my example data center = scenario: Customer with 10,000 VMs doing multicast + QoS + having multiple cores (say AMD = with 64). We would require 14 bits to encode all possible senders, 6 bit to encode = possible DSCP values and 6 bit to encode the cores. That is 26 bits of our 32 bits in = total. We only can build up very few of these SAs (<32 if we want rekeying with = make-before-break). The key issue is that we had to preallocate all these SPIs even if few = of them are ever used. Maybe I am seeing this all a little pessimistic, but I would not want = solutions that exclude each other, i.e. multicast SAs that do not scale over CPUs, etc. One way out is Tero=E2=80=99s suggestion to add the sender IP address to = the SA lookup. I have thought about this option over the last days, but I am coming more and more to = the conclusion that this is left out of the lookup for a couple of reasons: Most prominently = there maybe issues with IPv6 renumbering and multiple/non-unique sender IP addresses. = Furthermore, the IP addresses of the senders would required to be known in advance. All of this will = cause a lot of control plane overhead and possible race conditions in the interworking between = control and data plane. --Apple-Mail=_C3184BB0-DE5D-4FD4-9E2A-4FA56650560B 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/ZtCXI3ladZ37VLCzADDFAM3dskFAl8nyCIACgkQzADDFAM3 dslmqBAAvJ/fZLvWvhSn4Bn6t00Dh9coBc9ud9AdFEg6SQ3BSeUJkxRYNqowfHLF Ss85PKrXrN3lCRh9YQyuVs02KHLLXjG2Sy4NW8JUEWPM7u3X8GOFLHY3NQjOPMif cuzA0HE/wY2tMh9EFdF/B6e2QCw0JRiunqGtNmFqrZcauaSgZSFbikO7hfXUeanW 7gwpikpHrH8jXnuPLe/qYguJs1Gwl2PNocNAPABZe/TCPUrGGz6pqZK6qSRjrBeW SMEMXl4+tImNYPaAkUwL8Tv81ROsIq5zP2NwMq12gFdtr5Hdqa1wNL5odY20sX8I RtRR4UeocUpgx01For2CBiIMOBrrI/hOwOkSxFvvjuXc3CaswIstic5qP8IGqK8V NuWhzCoX4yVdvaAzEeYUGQhrz2+G5oQqTBbFaJO7Uun+YyqDT4U73Rx+K6zPxEV+ Q/CkBdBN1thBa4/XqW66qDWaACc+t+f7+hpU2Jl640PWKXcD8hcB8QNr9q2IDoEx 91v3pEvvVdbXvJo6Hi6Lum7G1jZ2ZPsOGZtfkL16wpxwv0n3SGB54hTnKg2fkUnh V95I23UHss5T12VUjbFQ+Ut1p/lPgqSlN0H3GdAhR0Z8G36lhzvoQvOpGMoVaf82 CmW6Kk4NCRefqdvh+vCunCZPbc7sQGS3bAZE7XHs2u71dPJay04= =6xPR -----END PGP SIGNATURE----- --Apple-Mail=_C3184BB0-DE5D-4FD4-9E2A-4FA56650560B-- From nobody Mon Aug 3 16:34: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 C9A493A116E for ; Mon, 3 Aug 2020 16:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.148 X-Spam-Level: X-Spam-Status: No, score=-1.148 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, NICE_REPLY_A=-0.949, 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 sJDP-k_ibNTC for ; Mon, 3 Aug 2020 16:34:10 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 7C84F3A116D for ; Mon, 3 Aug 2020 16:34:10 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id u126so3064619iod.12 for ; Mon, 03 Aug 2020 16:34: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=0wR1EtHg02Vv6JStTlaFKmBf8nmXA/4EMqMGUpEShiI=; b=WXXzrLnjR5zPsBZx0vVaGDtq7y9D1Lm6EccZkB7yMqSrIxbJXoH51npRRpGtlm8y05 Dxux3mdPkRtlB5niyWYlZ7imTWiyCoxuPX/LX/MU4nNOwvH8bkf2rQULMv10ytBEGhQL W2OO9bsgqyIGVOC0Hiq3nh35pSVzYKtW0F1MR7V0uJXvLLn59sJIhBZs1+Ep5f/LAkqV 65+NAn0QLIJfWCUidQVazLCFAZJMhGvTwWy7M3eXHhMPXIh0HmGdbuRIRghUw7ofcXj9 8SRPpWR/mO64Tr2ryj6ttthD480r3ApGX8teQVGKIaGZmY+/d3tZW8/POkV6bRZtg85I H9Fg== 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=0wR1EtHg02Vv6JStTlaFKmBf8nmXA/4EMqMGUpEShiI=; b=QCsMOeyphQxxMUPgIU/z6HUUG9SHDPBtqKjKMJVWOecXzJ8F/EToCdPG+xzWNNNLk2 0FWjGurEWPrgm5ljYDkSmOGnSHAloIxP15mx+UPwMMfr8tNfd5Fnmbx/3V8ElpI/TjT7 ARUx4UOVdB2E59iqdKw0i9JI16B7WWDU1fRIhmP3r1/YajQAhBKNEddVPm7NPYqySaZy 2txem6TbVmesRaHY8RUXOhDYj8ibj/mZPuM6Tx4/pEdeDxXNrfjR08sLuSV36weNtwL8 Y9K1I5yGdS2y1DeayUJW2Rro+UDXc3JGGT34WhG3uzagzXDFjsE4J5y0SWre7T2y9uPA GGrA== X-Gm-Message-State: AOAM531NyS74amzgmtVsf39vivHov86w2esr7hHTZ8vfnyoyoQKfvt2e cN72XZ30G2ojq+jKTpb79m0CoQAP X-Google-Smtp-Source: ABdhPJyK4NHMrsPq/EBNb/5IjEqNVc7tpcI2l1jUjtMjCMVNuFH2m8icnFYrgMLWkLeEiZIoAy2sPg== X-Received: by 2002:a05:6638:2493:: with SMTP id x19mr2527182jat.53.1596497649603; Mon, 03 Aug 2020 16:34:09 -0700 (PDT) Received: from Wastelandia.local ([2601:401:500:1218:c563:8693:7dc7:9793]) by smtp.gmail.com with ESMTPSA id g1sm277355ilj.62.2020.08.03.16.34.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 03 Aug 2020 16:34:08 -0700 (PDT) To: Michael Rossberg Cc: ipsec@ietf.org References: <023E45E1-B1AA-4042-A8E3-DD7457235BC7@tu-ilmenau.de> <03c7c0d4-698e-bf07-e3af-aaa2eb81221f@gmail.com> <1f464ae1-2f38-51ff-e087-269d033fc4cd@gmail.com> <703EBF8C-4A94-4329-B720-369B9180EADA@tu-ilmenau.de> <7e136b99-8a41-a2b8-caf3-100102407a2c@gmail.com> <91BA04C7-D68D-473B-A0DE-0E8DA19B7B53@tu-ilmenau.de> From: William Allen Simpson Message-ID: <8e38f76e-0f9c-e73b-6aad-fdccbfec9530@gmail.com> Date: Mon, 3 Aug 2020 19:34:07 -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: <91BA04C7-D68D-473B-A0DE-0E8DA19B7B53@tu-ilmenau.de> 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: Mon, 03 Aug 2020 23:34:12 -0000 On 8/3/20 4:17 AM, Michael Rossberg wrote: > Unfortunately I develop systems for a customer who uses DS for some (maybe non-technical) > reason. > Helpful to not use abbreviations. DS = storage Data Servers? AWS Directory Service? Microsoft Domain Services? > The issue I am struggling with: If there are multiple “reasons” to allocate blocks of SAs we’ll > have a lot of unused SPI space. Coming back to my example data center scenario: Customer > with 10,000 VMs doing multicast + QoS + having multiple cores (say AMD with 64). You know of a VM doing multiple bulk multicast tasks at the same time? 10,000 VMs sending multicast? Or receiving? As senders, 10,000 VMs would each have their own IP address; multicast senders don't use the multicast address as Source. Even in my wildest dreams, I'm finding it hard to envision 10,000 replicated data storage VMs. But in that case, they'd be receiving (object updates). So no matter how many cores, there shouldn't be more than that many multicast SPIs. (Or unicast SPIs for that matter.) > One way out is Tero’s suggestion to add the sender IP address to the SA lookup. Yep, several of us have mentioned this. My understanding was to check the Sequence Number for replay attacks, and for implicit IV generation. > Most prominently there maybe issues with > IPv6 renumbering and multiple/non-unique sender IP addresses. The stated reason for needing extra fields was to differentiate senders within the same implicit IV space. Renumbering won't hurt that. Indeed, would help! AFAIK, multicast sender non-unique Source IP addresses isn't allowed either. Are you planning on 10,000 VMs somehow sharing the same Source IP address? > Furthermore, the IP addresses > of the senders would required to be known in advance. Why? Again, it's just to keep the Sequence Numbers separate to avoid duplicate implicit IVs under the same secret. Define it algorithmically. No state. From nobody Mon Aug 3 21:16: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 A595C3A0B33 for ; Mon, 3 Aug 2020 21:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[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 GJGl98ctsXac for ; Mon, 3 Aug 2020 21:16:32 -0700 (PDT) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 78BC13A0B23 for ; Mon, 3 Aug 2020 21:16:32 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id p20so1138278wrf.0 for ; Mon, 03 Aug 2020 21:16:32 -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=PQxV5OxMnuUBkldCeLwxPEf1nTc8SX+5AOix/OU6xaQ=; b=liSNL0x30Y2VIQxni6AEigR3TTYetoJ8Df+Xa7uzm54bMgeVP22n0UL9eY0XNj/vl8 tvBJVUuxF/n2Y4bdgKKiV7zX0iuJ0bGd19BJ7tr2CTvTQS9T+KVOUUzpbAHIO3AfmPxa te+ttM3duPeItbY9Y2zUSx+VQxb5hDx4KV7zuARo1x12rzbksIB9sgjb/QWUtPLw1Sav YLaWrW635XTK6yePRlSg88E4BCeqT2r/QiPbj4YPUzR/j4hhqO6Xm2ShSowyzXcFLwlk 0UiQko13ZzHhfaKs4tcPNA+tkIze9fay7zGeTrzdlbLbGXoeixeXkvuHxc/hWpJ5TrJV oaxw== 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=PQxV5OxMnuUBkldCeLwxPEf1nTc8SX+5AOix/OU6xaQ=; b=luqezpRgEQweruU6XQmByrrLOk60YHN2ijSgLOL+6ix7ibmdFnRsj5HK2H0Z5OaIJ5 TJKcbGnVQcU2IEyZ+KBkb0mE2rQXmUSwo7poEpDnqYSZlh7tnMdO/M+W8gIDm0iC9Gp0 79bhQKVhXImuqUxDLzjh0zHdGlUK2fnQZX7tHBNmwVXVu15+YHjI3wiLUGFbeKyjiFjH TF9L0sCUoHCyXSEqLP7WKbx9WM9y0yVu/cTcIj2fcJUM+SEF8RthS+luPCCJenH74qb9 0qCtqgCyRZFtQKo4nVbMujx+TYsNl9ryr+6lMcXOUwUH1o9xGUKOfqJGqLuqZHtCt6mD cZjQ== X-Gm-Message-State: AOAM532iVH9dT9TkbSfSpteOTLFeN/ROCj7xCsEPQByBCmcLxrN4Ld1t n7Rr6SxqEuv0MF17dc/b2E4= X-Google-Smtp-Source: ABdhPJwdQ3v/nxoYMCdKZTtXv+cJj7WrTI1blzlqWfVre7VRKh761LhfEKdvi4JdpERITDthacNpxA== X-Received: by 2002:adf:dd01:: with SMTP id a1mr19023131wrm.301.1596514590870; Mon, 03 Aug 2020 21:16:30 -0700 (PDT) Received: from [192.168.1.17] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id j5sm2721654wmb.15.2020.08.03.21.16.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Aug 2020 21:16:30 -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: <8e38f76e-0f9c-e73b-6aad-fdccbfec9530@gmail.com> Date: Tue, 4 Aug 2020 07:16:28 +0300 Cc: Michael Rossberg , ipsec@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <05771224-711A-483E-8FE2-5D2E83530F1A@gmail.com> References: <023E45E1-B1AA-4042-A8E3-DD7457235BC7@tu-ilmenau.de> <03c7c0d4-698e-bf07-e3af-aaa2eb81221f@gmail.com> <1f464ae1-2f38-51ff-e087-269d033fc4cd@gmail.com> <703EBF8C-4A94-4329-B720-369B9180EADA@tu-ilmenau.de> <7e136b99-8a41-a2b8-caf3-100102407a2c@gmail.com> <91BA04C7-D68D-473B-A0DE-0E8DA19B7B53@tu-ilmenau.de> <8e38f76e-0f9c-e73b-6aad-fdccbfec9530@gmail.com> To: William Allen Simpson X-Mailer: Apple Mail (2.3608.120.23.2.1) 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: Tue, 04 Aug 2020 04:16:34 -0000 > On 4 Aug 2020, at 2:34, William Allen Simpson = wrote: >=20 > On 8/3/20 4:17 AM, Michael Rossberg wrote: >> Unfortunately I develop systems for a customer who uses DS for some = (maybe non-technical) >> reason. >=20 > Helpful to not use abbreviations. DS =3D storage Data Servers? AWS = Directory Service? > Microsoft Domain Services? Differentiated Service =E2=80=94 one of iterations of introducing = quality of service to IP packets. From nobody Mon Aug 3 23:00: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 0D2BA3A0D90 for ; Mon, 3 Aug 2020 23:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[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 I7hKyw_CeiKM for ; Mon, 3 Aug 2020 23:00:25 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 2BE3B3A0D8B for ; Mon, 3 Aug 2020 23:00:23 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id w25so6759579ljo.12 for ; Mon, 03 Aug 2020 23:00:22 -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=LjEh3hAmBVBHK8dcuI9jiXk0jFGgA+QU4KQPiJVu/GI=; b=Bh+Us7++r1o9OjsAQmYK7VDjgSXwiZNqyc6DRBqoJYQyZg+st2ZorJMA7g0IzSzuBu mRnBaTxe9xk72GWI5HjCfoRFtEdWB95gjL842Y5mJ7Kxj9H+RQ8Jgyfw6SrUFYPVcmvR cKvfjTSCelSD4IUtnbuPd82iM4I/1/hd+r+N3Y3SUs2N6MZ5ZE6SlVoMm3DB1YI8owot lZ5Ck9phFP9bAyo0UZYG5oO2rSYP3hu5YZyCz4OF36yBfToAtNs+O4lNUCtSjbqgHIzp n76SguinsGlCFD4azPRltNbHYwX4LUFWfPvdKmT5l/3UMa+IuzNELnlBBznRHn8b7ae0 ZRSw== 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=LjEh3hAmBVBHK8dcuI9jiXk0jFGgA+QU4KQPiJVu/GI=; b=jZc8sqvgsMELAFl4HXOUtargjHzGIyKdSaoMfs7TvuVvuQRj7FdKaDl04plxQtMUAj 8jME4aJk7C+Q5f3x+WLktIuC6m+7d0KZE5FLBiPE8j9ypgez8Q0XyR7RVJzLitiTztfP dQ8XWZLu/zVZ4G+n2h/Bjs4DaHX9+2izuKmkcX8HCH8FV858pEt7OLM11FBRuwTANnR2 Da8oXHujkHB9sTLA1WJ9mrmn43rUCDWebhUYTcMBrRNZjlDoJ7Ufc1kLBygzq0nW6ml8 vWF1FGEZDXAdlwt8MMund8LYfid3WG0HkPNOEe2JeVr3Jva8M5tjGzRPCVFVDpfRrBGN xQmg== X-Gm-Message-State: AOAM531Yx5yq7Bjm5SJZquzYpMH/D1VeZOCl4/RMuLAIMqevm7eOAI9a D7bXEDCBKKCwo+DBPhdvJQM1L5y3 X-Google-Smtp-Source: ABdhPJzDZ8qkq3vIhyPEBcrXd45JTmZ6ycErbitaNIlXojcOjK2m4+dSkkr8TpsmMyKUHqp7CnvMfg== X-Received: by 2002:a2e:9557:: with SMTP id t23mr9243401ljh.85.1596520820803; Mon, 03 Aug 2020 23:00:20 -0700 (PDT) Received: from buildpc ([82.138.51.3]) by smtp.gmail.com with ESMTPSA id y26sm5066429ljm.132.2020.08.03.23.00.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Aug 2020 23:00:19 -0700 (PDT) From: "Valery Smyslov" To: "'Michael Rossberg'" , "'William Allen Simpson'" Cc: References: <023E45E1-B1AA-4042-A8E3-DD7457235BC7@tu-ilmenau.de> <03c7c0d4-698e-bf07-e3af-aaa2eb81221f@gmail.com> <1f464ae1-2f38-51ff-e087-269d033fc4cd@gmail.com> <703EBF8C-4A94-4329-B720-369B9180EADA@tu-ilmenau.de> <7e136b99-8a41-a2b8-caf3-100102407a2c@gmail.com> <91BA04C7-D68D-473B-A0DE-0E8DA19B7B53@tu-ilmenau.de> In-Reply-To: <91BA04C7-D68D-473B-A0DE-0E8DA19B7B53@tu-ilmenau.de> Date: Tue, 4 Aug 2020 09:00:20 +0300 Message-ID: <18a701d66a24$897a9f50$9c6fddf0$@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/oDCzGyVFFVxgLLYkyNAhAEaFsBdxhddgFS0tfMAyB+QC+mxjaNQA== Content-Language: ru 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: Tue, 04 Aug 2020 06:00:33 -0000 Hi Michael, > One way out is Tero=E2=80=99s suggestion to add the sender IP address = to the SA lookup.=20 If you properly implement ESP, than you must have already included source IP for SA lookup. It was explicitly added to cover = Source-specific Multicast use case. And in case of SSM source addresses are not unique (however, all the = drafts covering=20 SSM are long expired, so I'm not sure it's widely or ever used). >From RFC4303, Section 2.1: Each entry in the Security Association Database (SAD) [Ken-Arch] must indicate whether the SA lookup makes use of the destination, or destination and source, IP addresses, in addition to the SPI. For multicast SAs, the protocol field is not employed for SA lookups. For each inbound, IPsec-protected packet, an implementation must conduct its search of the SAD such that it finds the entry that matches the "longest" SA identifier. In this context, if two or more SAD entries match based on the SPI value, then the entry that also matches based on destination, or destination and source, address comparison (as indicated in the SAD entry) is the "longest" match. This implies a logical ordering of the SAD search as follows: 1. Search the SAD for a match on {SPI, destination address, source address}. If an SAD entry matches, then process the inbound ESP packet with that matching SAD entry. Otherwise, proceed to step 2. 2. Search the SAD for a match on {SPI, destination address}. If the SAD entry matches, then process the inbound ESP packet with that matching SAD entry. Otherwise, proceed to step 3. 3. Search the SAD for a match on only {SPI} if the receiver has chosen to maintain a single SPI space for AH and ESP, or on {SPI, protocol} otherwise. If an SAD entry matches, then process the inbound ESP packet with that matching SAD entry. Otherwise, discard the packet and log an auditable event. Regards, Valery. > I have thought > about this option over the last days, but I am coming more and more to = the conclusion that > this is left out of the lookup for a couple of reasons: Most = prominently there maybe issues with > IPv6 renumbering and multiple/non-unique sender IP addresses. = Furthermore, the IP addresses > of the senders would required to be known in advance. All of this will = cause a lot of control > plane overhead and possible race conditions in the interworking = between control and data > plane. >=20 >=20 >=20 >=20 From nobody Thu Aug 6 10:22:37 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 DDA543A0D3A for ; Thu, 6 Aug 2020 10:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 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.949, 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 8yFDS8RDtz0z for ; Thu, 6 Aug 2020 10:22:33 -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 52EC03A0D2C for ; Thu, 6 Aug 2020 10:22:32 -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 D89EF1B0094E; Thu, 6 Aug 2020 20:22:29 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1596734549; 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=PRjrSe7ui/L8/H6lqeBRMZypS14IptjIZWlUf+/gJTQ=; b=tvd8hH5M+3drioUQRZ3p/PTrA/nHi0ic3a8reaisoC6A1LlvbAbJSYZx5/IuTGwUImqAOx bbSb44C6ndNaiJ+X6YnYItuDUP4sTowKLwLOzBJYfJpRZldGgmn6MIHGuvqEi+GmUJVJLO 5zTQkVqVaRkisbxhb5yoBkg0FJbnO95Dwv7wtFhXOldpulFodPZohiZ1Z7uuyQMXU2RDm0 /W5lwdFP4ANre7y75WSCIECrxFCP7t8xIblOmK6VTWqfV2D7ZJontN+BXoXq8EGlUHdU4p FNmNfaJlZXjY/F0aXL/SFFJbTgMHvrMo4GSwqboNjtocvhqEALxSnJpUW3WSSA== Received: by fireball.acr.fi (Postfix, from userid 15204) id AD47625C1149; Thu, 6 Aug 2020 20:22:28 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24364.15444.621102.781854@fireball.acr.fi> Date: Thu, 6 Aug 2020 20:22:28 +0300 From: Tero Kivinen To: William Allen Simpson Cc: Steffen Klassert , ipsec@ietf.org In-Reply-To: <97778198-87b3-e27e-6da9-b3ea83f62b29@gmail.com> References: <5484040d-3b40-d94a-634e-c182c9165634@gmail.com> <20200731083259.GG20687@gauss3.secunet.de> <97778198-87b3-e27e-6da9-b3ea83f62b29@gmail.com> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 19 min X-Total-Time: 19 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1596734549; 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=PRjrSe7ui/L8/H6lqeBRMZypS14IptjIZWlUf+/gJTQ=; b=ZwfOXOvyKTpce1Peh/tO8v4N66cIrRDOsQ7kG2wIwV8gAVhVQr3mFstJ49zgxU51v5B6Xv FoC/K/IiK9npCAxhL6rsroF+o9mFHoW6UCzlOeixQBfVzi3+LDn+rGlHZum2ArhtsNsPOV OthMY+BY0ZEUAz/UA7UlvfcrINhuAw7hmr+eAgUyxeD2xGnwsMU0BQplFrOtQBMqEChPlU 15+EeCheX65Rsn6iVhGIcZkLDz/g3oflvdSLQR+aWmh3Y8EykjoKgVnq3VHMntlhT4aSNr QaAnbKmITesnWQWglhMD9kz2p25bEQGXi2iY8ejKXxT98SEbQnpnRP+KMmqyNw== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1596734549; a=rsa-sha256; cv=none; b=ph4ezXd4i5gmiooozcQOjtbErSUYdaYf8ZbOslxHuBLIIbZxb2lZahsLY1KUQuEbKGFs8V CVctJaEgn/74l0fSeOf2jgnnJgyq2ng9HEdhuXYbj+/d1+haJsG7RU8in/GZusrg2ba1Y0 QQVdDC6Z7nhRBqcTHrdP9/uQz427sVmCVCWqH/witAmv1rEskjalE9HPjlZHy6atQrXWbm nP/ilc78+eD/pIxnN9RjQdUFUyiAjpMNm+ohBCM6vjzL7RUClGP0zfjKKhJCiAUbEdighZ lRvV400WiL/f0PvNHgfL546EyjIHENeTaT9kaU6SnrmYATwchaGOs4W/nYOfNQ== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi 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: Thu, 06 Aug 2020 17:22:36 -0000 William Allen Simpson writes: > > So it might make sense to have the ICV at the end because it is > > likely cache hot when needed. > > But after removing padding for these stream algorithms, then the ICV is > very likely not aligned. For zero-copy RDMA, it is rather inconvenient. > And the IP header cache lines are likely still hot. > > Anyway, that's why I'd like to consider at least a negotiated option -- > as long as it's possible to implement efficiently in Linux and others. > We need to hear from more implementers. I think it would be a bad idea to have such option. Yes, it might offer small gains on environments where the option is picked exactly when both ends like it, but when one ends pick it in a way which other end does not like, we usually end up big performance penalties. And also it again multiples the testing effort as now you need to add to your test suites this combined with all posible ciphers etc. This is was one of the main problems with IKEv1, there were so many different combinations of different options that to be able to test all of them required thousands or tens of thousands of test cases. Example of similar optimzation causing problems was found during interop events when some version (I think it was Linux) was sending fragmented packets in reverse order, so the first network packet sent/received was the last fragment. The idea was that when receiver saw that last fragment it can immediately know how big the final packet will be and it can allocate big enough buffer for the packet. Then when you combined that with IPsec with per flow policy, meaning each TCP/UDP flow might be using different SA, that meant that SGW required to store all fragments in memory until it got the last packet from the network, which was the first fragment, and only after that it could check whether this packet is allowed to pass, and which SA it needs to use. Then it sent the fragments out, but there was lots of added latency because of this. Actually I think there were also implementations which did not even store the later fragments, they simply checked the later fragments, and found out that they have not seen the first fragment that would allow them to be passed, so they dropped them. The SGW of course then sent the frames out in order, so that the receiving SGW can efficently do exit tunnel checks (i.e., check from the first fragment that this packet should be allowed, and match later fragments with same fragment id to that, and allow them to passed), and it then did not need to do same buffering. Of course the final destination host now did not benefit at all from this optimization as it was negatied by the SGWs in the middle. So immediately when the options to use start to depend on the platform, implementation etc it gets harder and harder to find out which will be the optimal combination between two devices, and they might end up using suboptimal feature set. And all of those add more complexity and combinations that needs to be tested. Of course if this option is added, it should be something like IPCOMP or transport mode, meaning it is off by default, and everybody MUST implement case where it is not enabled, then you would only implement (and propose) it on cases where it actually benefits you, and everybody else would never ever implement it. -- kivinen@iki.fi From nobody Fri Aug 7 20:53:03 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 27FBB3A0E15 for ; Fri, 7 Aug 2020 20:52:56 -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 vPAbxJvlmZYK for ; Fri, 7 Aug 2020 20:52:54 -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 AD0883A0E1D for ; Fri, 7 Aug 2020 20:52:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id BFC4A389D2; Fri, 7 Aug 2020 23:32:02 -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 XureY3T_VHHF; Fri, 7 Aug 2020 23:32:02 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E7644389D0; Fri, 7 Aug 2020 23:32:01 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 367F942; Fri, 7 Aug 2020 23:52:43 -0400 (EDT) From: Michael Richardson To: William Allen Simpson , ipsec@ietf.org In-Reply-To: <5484040d-3b40-d94a-634e-c182c9165634@gmail.com> References: <5484040d-3b40-d94a-634e-c182c9165634@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] 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: Sat, 08 Aug 2020 03:53:02 -0000 --=-=-= Content-Type: text/plain William Allen Simpson wrote: > 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. SGI did some extensive analysis on their multiprocessors around 1995. I have the references somewhere if you want them. I did a lot of analysis and reading (on paper, in the library...) at the time about architectures for parallel firewalls. SGI's conclusion (born out by architectures today) was that layer-by-layer parallelism (i.e. Solaris STREAMS) was a total fail. You have to keep the packet with the same CPU all way up. The Linux kernel has always tried to do this, and most of the focus in hardware systems is to do the inverse-demux as early as physically possible, and then stick with it. SGI also concluded, at the time of 100Mhz CPUs and no hardware assist, that the cost of doing IPsec (or SSL at the time), made the difference between these vertical and horizontal parallelism architectures unmeasureable. So might as well go with the one that works best for non-encrypted traffic, and is easier to code/debug. > 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? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8uIYoACgkQgItw+93Q 3WWCxQf+InkX0kWkcfc5Vh87B9konfXujwDhrrDnUnK+nTfA7l4u/AA1UMODHcrP Jpo26yYaXwifV2tGcC5Any8KqxhHnNAtF8k3PtKJky7IxnfTMFjUlqn7Jb5Z3LDs TA+T52DkF16zAO6NIxIX0iA4ABIPFWGW2Q1K3Jbjmb+QUg43VLWopNoS/NKB3snc rv7nQZ1ghiP736lv1vcslVA4TKG3VMduUz0lxuv/TduntRr5KkelQCVqTVrI95ml ojzpYMqrJISXnVNP5l+ecZUwCAfClNZKD4giZ1FVptsXprcY8Sa3F/KlP/URsmsf sYs9H9ze3ubBvmQ2xJ5udDBKjqr0Yg== =hKaG -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 24 10:09:03 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 1A60B3A13F8; Mon, 24 Aug 2020 10:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[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 QmzkFz5MQPaj; Mon, 24 Aug 2020 10:08:49 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 61EB63A1400; Mon, 24 Aug 2020 10:08:07 -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 7D6EF60981; Mon, 24 Aug 2020 17:08:06 +0000 (UTC) From: Christian Hopps Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_26AC4FAA-56C3-4C0D-AE98-B9A12CFF49FC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 24 Aug 2020 13:08:05 -0400 In-Reply-To: <159827985531.30993.17722282912726281276@ietfa.amsl.com> Cc: Christian Hopps , yang-doctors@ietf.org, i2nsf@ietf.org, last-call@ietf.org, draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org, ipsec@ietf.org To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= References: <159827985531.30993.17722282912726281276@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [IPsec] [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 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, 24 Aug 2020 17:08:58 -0000 --Apple-Mail=_26AC4FAA-56C3-4C0D-AE98-B9A12CFF49FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [adding in ipsec@] Hi, This draft was discussed in ipsecme at the last IETF, and there was a = desire to look closer at a couple changes that would make these models = usable by ipsec generally rather than only for SDNs. Otherwise we will = end up with 2 models that look very similar and duplicate almost all the = functionality. This was going to be done during the next yang doctor = review, but it looks like that happened in the meantime (ships in the = night). At minimum the module names should include "-sdn-" if no other changes = are made to indicate that they are only for sdn use; however, this is = not the optimal solution. A better solution would be to move the containers currently under = ikeless (for SA and Policy databases) under ipsec-common. The feedback I received from the authors was that the SDN controllers = didn't care about the actual SAs and policies when using IKE so they = didn't want to require someone implementing ike+common modules to have = to support them. The YANG question I suppose is, is there an easy way to move these = containers from ipsec-ikeless to ipsec-common, but still allow for them = to be empty and/or unimplemented for the SDN IKE use case? If they were = made features, is there a proper YANG way to indicate that if the = ikeless module is present then those features must also be supported = thus matching the functionality as defined by the current draft? Thanks, Chris. > On Aug 24, 2020, at 10:37 AM, Martin Bj=C3=B6rklund via Datatracker = wrote: >=20 > Reviewer: Martin Bj=C3=B6rklund > Review result: Ready with Nits >=20 > I did an early YANG Doctor's review of this draft. Most of my > comments then have been addressed in this version. >=20 > Comments: >=20 > o As I wrote in my early review, the RFC editor enforces a common > format of YANG modules, so it is better to adhere to this format > before sending the draft to the RFC editor. Use >=20 > pyang -f yang --yang-line-length 69 >=20 > to get a consistent look-and-feel for your module. >=20 > (You will have to manually re-flow description statements after > this.) >=20 >=20 > o There are some leafs that are optional in the model, but w/o a > default value and w/o an explanation of what happens if that leaf > is not set. You should find those and either make them mandatory, > add a default value, or explain what it means when it isn't set. > As an example, > /ipsec-ike/pad/pad-entrypeer-authenticatin/pre-shared/secret > is optional. I suspect that this leaf needs to be mandatory. > Another example is the leaf espencap. >=20 >=20 > /martin >=20 >=20 > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors --Apple-Mail=_26AC4FAA-56C3-4C0D-AE98-B9A12CFF49FC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAl9D8/UACgkQLh2DDte4 MCX8sg/6Au9kL2xfzKcvN4A2xM9hMV0err+41YYYQyf8X1qCwrkTJsrCB/utxOrC EXFJ4328pzMAjtQzR4X1ptsjswTfoOcaJ/FRx8oTNzOM1IBw8XnuOIvDOGpv+CEk 4fKfeADsHNpdKMMEAHZFGxcmUcybQvV0mzOuWCdRQtz9H22baM9aLVi4VA0DRikU dV/qgMFSQ4qO1onNcMae0uCFm1Zeh+anJ5Ys1xlN8zOm0OvgixdIa9uSVlINZje/ qHqgaHzfk7IxZ8LWh/ivnBUa5rKG78vQ6ppIzB3/lcT/KBZZM1YA7nI/T9lnI41E HCpTtHtsIfRV+4hJiOhGVhJff8RXYVUDkHaDp2oHgMAxhAoUYdRNeeadU8cIIJfu 5HlTYHm3T3eVQmHG3qk2NWQsNa+xgNIgSnJFW/HD6r1kRqEMD9Ux5jxf9bLRljGM b5fjiCJrllrYMaiyT4Ib/Unu596cP83jFmF4t27yULx52RPnyTL7JjLqgX1ZIlsq pZpwXrKn6hqsM4RIPeXbLmcdTHAbNaHAnua5Mv5Pe8x6p0/6b3nUQkeLykg8/ul9 apJueCgfWMN70UWcUBGVJHGamiUYtekqg9VQtjOVRo9PVA7ORafS4PAPF54L1mfA QVkdvIKRp+izMeSZJMkduszDjEraUNeH4lpRHOZ82NIVbSNctiM= =pNZI -----END PGP SIGNATURE----- --Apple-Mail=_26AC4FAA-56C3-4C0D-AE98-B9A12CFF49FC-- From nobody Tue Aug 25 03:22: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 994EA3A0C1E; Tue, 25 Aug 2020 03:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPXIt2s6qV_U; Tue, 25 Aug 2020 03:22:46 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70108.outbound.protection.outlook.com [40.107.7.108]) (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 5481C3A0C1D; Tue, 25 Aug 2020 03:22:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RUvvmljTu9hIz9CHuB7U/iZ6llfpqchiuieF/eYAYTN3t75FDrQtVQh9DLUR/mXovBdT5y4j9BiqrkybuA+ZAkI4x1Rt7ZzYA1d3Gvr03sVwE4kjG5Gva8eI3YxqWqrADa2nmr9RPmkAz5R3LixeUh5RSANCZFYOmKfQIs4mL4v5Ry4pU0Qpdd9O43cLkPJWdXVPV2SoMCwJGBqoVvWZIJLGW8uGPK26IPEEJFAAQNNEIWUeZ70E3S8KYISWwiJFBTwtnXpi/tF1wYygM0EUsepwBF6gTb35Om0oTlDcrvAh0vWrO0Br0hhnivncS74TZmni/eihOIMykPVnkjn9ig== 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=q+1wL0zByJqb/uh2lEYsX1gXS8pkn34V9aVSRIf3nS4=; b=QWt10SOS45/ZjOIKDAjLtDVWYYOA+S0jGuV2xs1Ij34Dptd/JMPbM7OLnm62uj+WbusMXucFFlC8W5Bmeu6l7D+zDw5lrUAYcXKnxKeM3vgdeWsuFjx1wa50cDtlnrtJ7Y1KFoPqTMBlpmLA7IYyH+1SwSgfq5VciHMHaKyi7wMZyNw3KIe1/RidiUnNqOSNdCJbliZBB5x7ztHcsvSk14LzAKvwr7mVVYFxKFG1v0w8y3Kxiv5n+3eGNIhW6mHq3As3/2vPJNacDfrPmpEdlslW8pC9O3elMzdFW6O5H8yhj5ghmF3/roIrYvYvww57JDPfwSWw0cMrcRY0ZMJ0jQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q+1wL0zByJqb/uh2lEYsX1gXS8pkn34V9aVSRIf3nS4=; b=SUOzJVAhJ3/6okAJFhgC0xQYBJQRcXB7Ul/fbrRNMigkMeaqvk0Wv6JwAJr6xpJFKUgKfPTsgHh10RahNEIqlO3RrHYUn/wHlV8lUHI3a+QpnIYDszqIhLm9MvYkvzWoQrKX5IkY8AcOilBKfCgVVxi0nXdUDkIO25vUgCEJdNU= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=btconnect.com; Received: from VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) by VI1PR07MB4191.eurprd07.prod.outlook.com (2603:10a6:802:66::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.10; Tue, 25 Aug 2020 10:22:40 +0000 Received: from VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6165:9c1c:e5b1:15db]) by VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6165:9c1c:e5b1:15db%4]) with mapi id 15.20.3326.017; Tue, 25 Aug 2020 10:22:40 +0000 From: tom petch To: LAST-CALL@ietf.org Cc: i2nsf@ietf.org, rdd@cert.org, draft-ietf-i2nsf-sdn-ipsec-flow-protection@ietf.org, i2nsf-chairs@ietf.org, ipsec@ietf.org Message-ID: <5F44E66D.6080408@btconnect.com> Date: Tue, 25 Aug 2020 11:22:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO2P265CA0360.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:d::36) To VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.65] (86.148.49.170) by LO2P265CA0360.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:d::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.3305.25 via Frontend Transport; Tue, 25 Aug 2020 10:22:39 +0000 X-Originating-IP: [86.148.49.170] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 69bfb05e-9e60-489d-f105-08d848e0cbc5 X-MS-TrafficTypeDiagnostic: VI1PR07MB4191: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:5236; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: tVkyJipd6sMEeiUj5NGwZQvndIS39EFI4nsUqgd6N9lMDYlvNoIUQkMMzv+QzxsUgp4EIkxD3gxK/iVD++CH58FpfGHT1Nk2CsE/SQr/OX8Z2Lvv8JpawVQc9Fl5mcbnuMEy90lhWapsIBkGfDWQckvPlp1HRtkSLAEkg/yUIAOW391fD7O/VEJU4+AdDZF+SgTi2tW3a/7vCeMXOEdNmVLNQin5j2+UsqyWcyO9uIik5IkxISwSD/JDVrUEgLe9H+Uwdge/Hx7HP4WZtz2WfOoAsJyZxiPdH2NcX8wWOzcIs5K0v4JKR+khmJfAttSqufewC7zK4svfcKp+PauwNcH7rv16Oox4OdKbuZbUI22whbRtlNpr/lbMPVP9kmhH3gpjD803wNtFLty+azYH6w== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB6704.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(396003)(136003)(346002)(376002)(39860400002)(52116002)(16576012)(478600001)(4326008)(2906002)(966005)(33656002)(8936002)(8676002)(66574015)(6486002)(86362001)(956004)(26005)(2616005)(186003)(5660300002)(36756003)(87266011)(316002)(83380400001)(66476007)(66946007)(66556008)(16526019)(6916009); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: 4kq3jj4HJgN0di8OruS0P+PVtK6+dBs4lpAQFWAOHpZNWjRZw5DYvhLF3LZz0J8TthehLJrhtniY/5N15OecijGGOThy2WqtZ9wmmxGOzlmq80s42ePpWOhfKH3j6ibQE8upiM0fD4OmaNqeZmsEvZPejH3PwID8IRZjw68LZF2xnzfOUm3+tJVM50oh2FStf0i2amkWg3Jtyq/3A9xiZNQhoEMAt4tsFjSXBrcQ4mYjNIJ1xI8RPtfHBCE0uTAmr/6Td0TG3kkAd9gel18bOee0do4f7CCUnDeYUWWUjBTmwzcxFKFlEuuS9Dv+77/u4GxPLodpyc2akgcNGuc0xFA2UdUtCExlt62HosLHWtQTvpYnl90EcvS1yVYzvsg8dCqF2+ez7chO4SU/W7difNpFv6Mdhm5xPKqbUedlONznH685fNV2Lkv5rOrX0SGz7OI+db1EPCiuMkpCXr4qB5oAcdhHIixDQ8JvbTDo1vLfBVrSJrYRUutyBlUfUx1QpHla7AhmXJZLaLkDQoSf6MBme0/dkZdr13/V1Z/9M1UZWMkhw8TZ7ytDGX8adAqGaWEV1HSjORkPTfMzG1GMXxV3YYDGda5LO1lHVYaXuUGHHIWaZq/Jj21YvnaGDeql959vycoinm6dWxMdZwQIlg== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 69bfb05e-9e60-489d-f105-08d848e0cbc5 X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB6704.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Aug 2020 10:22:40.3109 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 4tON04vl9pCz0siuCwXiRpRL1DqRIGllb1xEO9mcXgp/3RObx29Tu6KAMprvi2XsQlR0uBhsqwrHHYrviKkr3g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4191 Archived-At: Subject: [IPsec] Last Call: (Software-Defined Networking (SDN)-based IPsec Flow Protection) to Proposed Standard 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, 25 Aug 2020 10:22:50 -0000 Looking at the YANG module from a different perspective from that of a YANG Doctor or a IPsec WG Chair, there is quite a lot of editing needed. '2019' appears 10 times and I suspect most should be 2020; one is an import by revision which is uncommon because of potential, future, compatibility problems. Conventionally, Appendices are Informative and YANG modules are Normative so if you want the modules to be Normative,I suggest adding to Appendices A, B, C 'This Appendix is Normative.' YANG is version 1.1 so RFC7950 is required. I suggest adding [RFC7950] to YANG in the Introduction. For IANA considerations, RFC6020 is the better reference. NMDA[RFC8342] conformance should be stated as appropriate YANG'import' need a reference; I see five without Tree Diagrams need explaining - RFC8340 does that 'revision' should be 'Initial version' at this stage with a reference to this I-D's title Lots of references - good - but they need to appear in the I-D References, mostly, probably, Normative. I see no I-D Reference for 822 - ood 2821? 2247 - 3280 - ood 5280? 3947 - 4303 - 5280 - 5915 - 7383 - 7427 - 7619 - 8017 - 8174 - 8221 - X.690 I-D Common YANG Data Types for Cryptography IANA Registry Internet Key Exchange Version 2 Parameters IANA Registry- Transform Type 1 IANA Registry- Transform Type 3 IANA Registry Protocol Numbers and they will each need a reference from the body of the I-D such as 'The YANG modules make reference to [RFC2247], .... I note that RFC822 and RFC3280 are Obsoleted which makes their use problematic. s.8.3 /The YANG module/The YANG modules/ IANA Considerations The Registrant contact is usually the IESG The prefix registered for ipsec-common is not the same as appears in Appendix A For the Web address, it is unusual to have '/about' grouping port-range with a range, it is usual to specify how a single address is specified, e.g. the absence of 'end' or 'start'='end' and for a YANG must to require end>start or end>=start as appropriate. The use of key 'start end' implies that 'start' and 'end' must both be present. Tom Petch The IESG has received a request from the Interface to Network Security Functions WG (i2nsf) to consider the following document: - 'Software-Defined Networking (SDN)-based IPsec Flow Protection' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-09-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes how to provide IPsec-based flow protection (integrity and confidentiality) by means of an I2NSF Controller. It considers two main well-known scenarios in IPsec: (i) gateway-to- gateway and (ii) host-to-host. The service described in this document allows the configuration and monitoring of IPsec information from a I2NSF Controller to one or several flow-based Network Security Function (NSF) that implement IPsec to protect data traffic. The document focuses on the I2NSF NSF-Facing Interface by providing YANG data models for configuration and state data required to allow the I2NSF Controller to configure the IPsec databases (SPD, SAD, PAD) and IKEv2 to establish IPsec Security Associations with a reduced intervention of the network administrator. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce . From nobody Wed Aug 26 17:52:06 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 EA76F3A0BFC for ; Wed, 26 Aug 2020 17:52:03 -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 G3degGJ4ebA2 for ; Wed, 26 Aug 2020 17:52:02 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E33B3A0BFB for ; Wed, 26 Aug 2020 17:52:01 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4BcPM31JzyzFn3; Thu, 27 Aug 2020 02:51:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1598489519; bh=hn3hgLHmQBjzqUHkPuBQSRH4FDIhfJEZ9yB++VF0QtI=; h=Date:From:To:cc:Subject; b=Uh3Ylike8QK4E62cWu6g4GYKDSUaY/blgZRP42mUy150xM7Qibm3tfzYf4dfHB1pK iSnXCLYEmlp+dUEou94KNq/eNoN8B/hR+u93DIuQggGhzi20xhKx2MuFBqbB5oMwyt LZWcpzMyG9x9k9sbaGsgeaTvmIFa9VrfX382INvU= 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 Dueea9mnPPHF; Thu, 27 Aug 2020 02:51:57 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 27 Aug 2020 02:51:57 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 1655A6029B99; Wed, 26 Aug 2020 20:51:56 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0DF4E669F1; Wed, 26 Aug 2020 20:51:56 -0400 (EDT) Date: Wed, 26 Aug 2020 20:51:55 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" cc: Nupur Agarwal Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [IPsec] Question on RFC 5723 Session Resumption 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, 27 Aug 2020 00:52:04 -0000 Hi, We are working on implementing IKEv2 Session Resumption. https://tools.ietf.org/html/rfc5723 We are only looking at ticket_by_value at this point. It is unclear to me what is the behaviour related to Delete/Notify. The RFC only takes into account situations where the connectivity is lost and any delete/notify messages would no longer be received by the responder. It states: When the client wishes to recover from an interrupted session But a client could use this mechanism when it wants to go to sleep and tell the server this as well to avoid liveness probes. So the initiator could send a delete, then come back later and use its ticket. This would allow the responder to remove the state without waiting on liveness timeouts to trigger cleanup of the vansihed client's state. If the responder does not keep any state (which is the goal here) then it would not know this session ticket belongs to an IKE SA that was deleted by the initiator versus deleted by the responder's liveness/timeouts. The RFC gives no guidance on this. Similarly, if the responder keeps no state of the tickets it issued, it would not be able to detect a ticket being used more than once without the lifetime it set within the ticket itself. When multiple gateways can read each others encrypted tickets, you could also not prevent a ticket from being used more than once. We are interested to know if any implementer bothered to track the issued tickets and remove them from a list when received back (or timed out) We are also interested to know if anyone prevents resuming a session on the server side if the server has received delete/notifies for that IKE SA. Paul & Nupur From nobody Thu Aug 27 00:47: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 1A9873A0E2C for ; Thu, 27 Aug 2020 00:47:04 -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, MIME_QP_LONG_LINE=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 8d4knaMp41LV for ; Thu, 27 Aug 2020 00:47:02 -0700 (PDT) Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) (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 68EE13A0E27 for ; Thu, 27 Aug 2020 00:47:02 -0700 (PDT) Received: by mail-wm1-x343.google.com with SMTP id x9so4221070wmi.2 for ; Thu, 27 Aug 2020 00:47:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=Zq1HbyKV4TP0FESh5VDJTByCzje/M419UhLtm8AJsQc=; b=fEA8HyvakvEp/TqOVRjHMmlBSwxhR1UoYRo3Ye7RrO0T05tJhKe2TRguSSBjqeh9vZ FAdvMLm/2XMOd4ubHKtCJGwk3Ied3e3ClD6KJZBW2E0fLlN6vpW6VhuVvgnnxp2es0FU 1rW9qj+XULNhhm7YFOtXcAFCpGE7GuG5QMpacvzGxpKMuaMWsytvvCxJpYoNRBFgL6+s wDknffqSD+tZWfc7AO/aWETdkO8qUPnUoE7xdk/XoH+zMRkA6o4VNtNT+odqNEJSvhF6 hsQkbfEFt7I8M7WfxjG7jGrrPLfhIihUFd4nf2BKK9vk4L3uSzhwpsDHVqwDNb9eigli bBrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=Zq1HbyKV4TP0FESh5VDJTByCzje/M419UhLtm8AJsQc=; b=sNSWXEtMFf9FR6YIhOGUa+pdRFYdsIVlSUDgcVnnQJIgfTBgr9erIW0riekFEKo5Qa kdRb2x4wc6pMXvqbzE+OkZAIiu+uycN6lHBEmCngVAp38O0d6LcXz0VVIDAOV2RzPp6c 0nov44n06WWioN7HW8nbVTsNeLmhk1rKfAieESQPQ7a2krt1UEMNxCVs3rzyR1N+wruy m3vkO0g1EjG78n4M8q0wveXLombzVOIblxA4ieP7D+s1vULGx9VGvSckOHqOgLMmdExl W6oCOvOQhHm1NM1LMBMqU4jcEku7kTGPhR6ZeT+H40a/lNv92JJbGG00dU8IRN04QrAQ 5e+w== X-Gm-Message-State: AOAM530XessJ3fFJmF5c+q1f4EwEpZuqRpi8OqIqCVAtBEoJR+ZeU3N6 LrDbK58iImUoj2lI0vPCbjU= X-Google-Smtp-Source: ABdhPJzFVpqHJAO+TtKoCmrii5R0IGWKGWOyE/2IsEBIPgsjWSwmICjj1GtZdHNWaiRP68Tnb22bTg== X-Received: by 2002:a1c:1d17:: with SMTP id d23mr9751552wmd.187.1598514420709; Thu, 27 Aug 2020 00:47:00 -0700 (PDT) Received: from [10.0.0.140] (bzq-109-67-98-145.red.bezeqint.net. [109.67.98.145]) by smtp.gmail.com with ESMTPSA id 3sm3173960wms.36.2020.08.27.00.46.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Aug 2020 00:46:59 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.40.20081000 Date: Thu, 27 Aug 2020 10:46:58 +0300 From: Yaron Sheffer To: Paul Wouters , "ipsec@ietf.org WG" CC: Nupur Agarwal Message-ID: Thread-Topic: [IPsec] Question on RFC 5723 Session Resumption References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [IPsec] Question on RFC 5723 Session Resumption 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, 27 Aug 2020 07:47:04 -0000 Hi Paul and Nupur, I would also be interested to know what people implemented, because what yo= u're suggesting, while possibly "the right thing", is clearly counter to the= RFC. Sec. 6.2 and Sec. 9.8 are rather clear that no matter who deleted the = IKE SA, the ticket is revoked and must not be used, and in fact the gateway = must keep some limited state to ensure it. So if you want to stay compliant with the RFC, IMHO you'd need a new notifi= cation for this "delete". The case of a cluster of gateways is not handled by the RFC. This is allude= d to at the end of the Introduction. Thanks, Yaron =EF=BB=BFOn 8/27/20, 03:52, "IPsec on behalf of Paul Wouters" wrote: Hi, We are working on implementing IKEv2 Session Resumption. https://tools.ietf.org/html/rfc5723 We are only looking at ticket_by_value at this point. It is unclear to me what is the behaviour related to Delete/Notify. The RFC only takes into account situations where the connectivity is lost and any delete/notify messages would no longer be received by the responder. It states: When the client wishes to recover from an interrupted session But a client could use this mechanism when it wants to go to sleep and tell the server this as well to avoid liveness probes. So the initiator could send a delete, then come back later and use its ticket. This woul= d allow the responder to remove the state without waiting on liveness timeouts to trigger cleanup of the vansihed client's state. If the responder does not keep any state (which is the goal here) then = it would not know this session ticket belongs to an IKE SA that was delete= d by the initiator versus deleted by the responder's liveness/timeouts. T= he RFC gives no guidance on this. Similarly, if the responder keeps no state of the tickets it issued, it would not be able to detect a ticket being used more than once without the lifetime it set within the ticket itself. When multiple gateways can read each others encrypted tickets, you coul= d also not prevent a ticket from being used more than once. We are interested to know if any implementer bothered to track the issu= ed tickets and remove them from a list when received back (or timed out) We are also interested to know if anyone prevents resuming a session on the server side if the server has received delete/notifies for that IKE SA. Paul & Nupur _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Aug 27 08:18: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 21C983A0DDB for ; Thu, 27 Aug 2020 08:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, TVD_PH_BODY_ACCOUNTS_PRE=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 1wJ6BXqknohR for ; Thu, 27 Aug 2020 08:18:29 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CF583A0DCC for ; Thu, 27 Aug 2020 08:18:29 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4BcmZq0qZGzFpy; Thu, 27 Aug 2020 17:18:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1598541507; bh=jdYXO9PSRNe0dfmaFMvdtG3noy2jzcPV3v0/ZfXRte8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=NuP/L4kN31gs3cIPpsWROqrIG/S+ZTYX936NWftviQYYZIdUSNQxUUlskDwE2Tz4F P8WhcDXvjztxRJiUHv8zpRAmhP94OTXgPuCzFmDkh2E1wBzFC7oR4yK23tPwq8A2yF AH3UP6qjFPUad2nO8bVlm+Pj57067UYWDi/Omc/g= 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 DnRVpFNHJVg4; Thu, 27 Aug 2020 17:18:25 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 27 Aug 2020 17:18:25 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 57482602980C; Thu, 27 Aug 2020 11:18:24 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4EF29669F1; Thu, 27 Aug 2020 11:18:24 -0400 (EDT) Date: Thu, 27 Aug 2020 11:18:24 -0400 (EDT) From: Paul Wouters To: Yaron Sheffer cc: "ipsec@ietf.org WG" , Nupur Agarwal In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Question on RFC 5723 Session Resumption 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, 27 Aug 2020 15:18:31 -0000 On Thu, 27 Aug 2020, Yaron Sheffer wrote: > I would also be interested to know what people implemented, because what you're suggesting, while possibly "the right thing", is clearly counter to the RFC. Sec. 6.2 and Sec. 9.8 are rather clear that no matter who deleted the IKE SA, the ticket is revoked and must not be used, and in fact the gateway must keep some limited state to ensure it. You are right that section 6.2 is clear, but it does not take into account the asynchronous nature of the client or server deleting the IKE SA and the other peer not getting that notify. So the phrase "no matter who deleted the IKE SA" is interesting. If a client "vanishes", it is expected that the server would cleanup state. Otherwise, the RFC would have just been about sending a notify to "freeze DPD/liveness probes" and leaving state dormant on both sides. It is inevitable that the server will either linger the state, or delete it. If deleting it should be interpreted as "no longer suitable for resume" than we are left with "lingering the state". At which point I guess we can accomplish the same with only MOBIKE, and we should move this RFC to Historic. What I liked about resume is that the client can legitimately "vanish" and cheaply restart without the server losing state or having to keep all states around for too long. Eg with MOBIKE you run the risk of the server removing state before the client re-surfaces and sends a MOBIKE UPDATE message, and the client has to go from scratch with a new DH. With resume, we avoid the DH and we can appear from a new location. And the ticket expiry within the ticket ensures the server won't start too old session tickets handed out. > So if you want to stay compliant with the RFC, IMHO you'd need a new notification for this "delete". Or update the RFC with a clarification that delete's are allowed, but that the server who deleted a state, upon getting a ticket MUST check: - It's configuration is unchanged from when the ticket was issued (we do that) - The ticket's issue time plus the configuration's lifetime is not in the past - The IKE SA should not have been rekeyed [tricky without keeping state] > The case of a cluster of gateways is not handled by the RFC. This is alluded to at the end of the Introduction. that was an unfortunate easy way to not address the problem of syncing state between servers :) Paul From nobody Thu Aug 27 11:55:00 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 96A743A1209 for ; Thu, 27 Aug 2020 11:54:51 -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 h4jMH9LSAh7y for ; Thu, 27 Aug 2020 11:54:49 -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 B80713A11FC for ; Thu, 27 Aug 2020 11:54:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 26DCA389D1 for ; Thu, 27 Aug 2020 14:33:49 -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 OJeeFoMidbjG for ; Thu, 27 Aug 2020 14:33:48 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 58AE0389D0 for ; Thu, 27 Aug 2020 14:33:48 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6BD56795 for ; Thu, 27 Aug 2020 14:54:47 -0400 (EDT) From: Michael Richardson To: "ipsec\@ietf.org WG" In-Reply-To: References: 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] Question on RFC 5723 Session Resumption 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, 27 Aug 2020 18:54:58 -0000 --=-=-= Content-Type: text/plain Paul Wouters wrote: > Or update the RFC with a clarification that delete's are allowed, but > that the server who deleted a state, upon getting a ticket MUST check: > - It's configuration is unchanged from when the ticket was issued (we do that) > - The ticket's issue time plus the configuration's lifetime is not in > the past > - The IKE SA should not have been rekeyed [tricky without keeping > state] If the ticket was issued at time A (which is in the ticket), and the IKE SA rekey time is intervals of time B, then had the SA been active alive at time A+B, it would have been rekeyed, right? So, if the current time is > A+B, then the IKE SA should have been rekeyed? But, you alude to it requiring state, so there must be something I don't understand. >> The case of a cluster of gateways is not handled by the RFC. This is >> alluded to at the end of the Introduction. > that was an unfortunate easy way to not address the problem of syncing > state between servers :) Can you explain what the problem is if the ticket is used more than once (with different gateways) within the time B? It seems that this is the only thing that would require state to be exchanged. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9IAXcACgkQgItw+93Q 3WV/rwf/dmcUbiecUG49tPQujSerTiJjS2zYRFwqxL0HaM9/BOpb6AW5L33OcbZq llWuLPJTMPCDxNwanhlqbXXeUEQjxeY5nMyH89XOhkRkwn6SVooINTuQIEsE8Y36 Tk5ZaU8aSv9vTIGRW7IS/fO9Aq2j4DuIIedXE7I4zs2QDRWbRLUkLMDZg493vCBv eJKZQ/Uyj0HGl0McfGnLoR7dZPuXGIG1iko615TiDCBJ2RgM+jLi2KccSp3ayfKC RsxEx6XhHczAkZdaCc4tbynffr7jhOYsG9CQ7xs6rQNJgUYtdFHb3lgzqEGWulTr 45UUf9Y+pP8ZnWQ85BwruU1Vex0SPQ== =3nf0 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 28 07:12:30 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 15C0A3A0B56 for ; Fri, 28 Aug 2020 07:12:28 -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 jVjbZaaVhzKx for ; Fri, 28 Aug 2020 07:12:26 -0700 (PDT) Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) (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 489143A0B32 for ; Fri, 28 Aug 2020 07:12:26 -0700 (PDT) Received: by mail-lj1-x243.google.com with SMTP id t23so1478258ljc.3 for ; Fri, 28 Aug 2020 07:12:26 -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=5+KeMZ6krZpGD6MV2Hy37x0ezmpL3x10KmRGUnRUA3o=; b=A7Q/gmYzoJstlOfy0pupKU1thkQsSNa0DXhbt572DWnZMN9FcPTGOkzBzGm9eM/+J0 /NCjbzRQP0WlFa+oa+8EXC1xRDXuQkx268RACLHHBurosYvaTFGILqY2SknzRS7GC/9r j0T/Nvz9s/uBsC21xoHwskcvESnPTzCkp+VI9SrUMMkIldc7fUjqo9Pob6lrQML/r9jg m6wpHJaHPZQZwakSBZ7QKFB779ojBkawe6fCrqDv+SrfiN6sfdaArBbbm8wb97S/StKa OsIgrBE74sOtDlYMT8i7FOAn2uYhrQcJgefGq0/8sOcnJrfrUfHLf6WFTn6YEYX9oNda 0TNg== 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=5+KeMZ6krZpGD6MV2Hy37x0ezmpL3x10KmRGUnRUA3o=; b=FkeUO4h3MV35o0VCDGO5NwW68g1XO9eXV6+A3hKa3+eflZGJ+0tgEP1g1H6ItBIVly Vwbeph7hhJXLtXW/S5MYK7mvl63YAwrGggixSFIVL3WLcDp9yoqsZZK9B4qFs3O2gB1Z YMTVVfsocCJhDnUCccGGgYcdgttcWI9W/oG0pqG0ZwTZ/Pam7OUoapQPJuMc7QPbgs0T 8wLdkMg3EAmjsaL+w8R4kxYTqcOX6kXsToB8RjQAzcDuVVfM6TvvaUTQNw98EzfZuC6s 5CUbO+DvJuMKW/5uVDIDyJ6+CkYrrYymmpKy+VaK2WotXqiKdY6L3TC1Bdtq+KkQrCiU InoQ== X-Gm-Message-State: AOAM531gfUNcwWIik/adf2xQeY/Ig8rUpI0Zbj0puGnwa2d+/LKQtfbG cfQLJqBScagMqySlbW0Gb4ID6xBXbuY= X-Google-Smtp-Source: ABdhPJxy99saAZQmQoEGlyXcg50q/nHtrYY7pcd5/UG89KPMlieBuLWNGZZa11p51BLXlxhPbQwYHw== X-Received: by 2002:a05:651c:513:: with SMTP id o19mr1022297ljp.379.1598623944063; Fri, 28 Aug 2020 07:12:24 -0700 (PDT) Received: from buildpc ([82.138.51.3]) by smtp.gmail.com with ESMTPSA id x17sm232781ljm.0.2020.08.28.07.12.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Aug 2020 07:12:23 -0700 (PDT) From: "Valery Smyslov" To: "'Paul Wouters'" , Cc: "'Nupur Agarwal'" References: In-Reply-To: Date: Fri, 28 Aug 2020 17:12:16 +0300 Message-ID: <00f701d67d45$3c2b62a0$b48227e0$@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: AQLu9y+F8Hx7VjEs5Up2N5/HjUuRUaccmnoQ Content-Language: ru Archived-At: Subject: Re: [IPsec] Question on RFC 5723 Session Resumption 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, 28 Aug 2020 14:12:28 -0000 Hi Paul & Nupur, > Hi, > > We are working on implementing IKEv2 Session Resumption. > https://tools.ietf.org/html/rfc5723 > > We are only looking at ticket_by_value at this point. > > It is unclear to me what is the behaviour related to Delete/Notify. > The RFC only takes into account situations where the connectivity is > lost and any delete/notify messages would no longer be received by > the responder. It states: > > When the client wishes to recover from an interrupted session > > But a client could use this mechanism when it wants to go to sleep and > tell the server this as well to avoid liveness probes. So the initiator > could send a delete, then come back later and use its ticket. This would > allow the responder to remove the state without waiting on liveness > timeouts to trigger cleanup of the vansihed client's state. > > If the responder does not keep any state (which is the goal here) then it > would not know this session ticket belongs to an IKE SA that was deleted > by the initiator versus deleted by the responder's liveness/timeouts. The > RFC gives no guidance on this. > > Similarly, if the responder keeps no state of the tickets it issued, it > would not be able to detect a ticket being used more than once without > the lifetime it set within the ticket itself. > > When multiple gateways can read each others encrypted tickets, you could > also not prevent a ticket from being used more than once. > > We are interested to know if any implementer bothered to track the issued > tickets and remove them from a list when received back (or timed out) We don't (as for now). We implemented ticket_by_value, so server is stateless. > We are also interested to know if anyone prevents resuming a session > on the server side if the server has received delete/notifies for that > IKE SA. We don't (as for now). We rely on client's honesty :-) This is probably wrong and needs to be fixed... Regards, Valery. > Paul & Nupur > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Aug 28 09:07: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 7B4993A0D76 for ; Fri, 28 Aug 2020 09:07:46 -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 1AG6pGAFYKYK for ; Fri, 28 Aug 2020 09:07:45 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2E6D3A0D75 for ; Fri, 28 Aug 2020 09:07:44 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4BdPdB67t2z5Br; Fri, 28 Aug 2020 18:07:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1598630862; bh=URWVwOqIsyVHQMu5/v9FntGvVhVd3934XksW/IJXnqs=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Ju+M0SE1LjClsk1P+O1FjbG5lVY0c4cxmjdtt/p6MbmCEfWRJwFwZMRiTmlnkYOIj ViyJIMaxNwbqdqQkkdtP+TVokq3ujLSy8hLh/2Uymo5q79dikfujzGts5xRx823zSl eRHH5MQTleM8tgXAngdM1X33PHtbZYv7Xhgairys= 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 dmjEimXsVZYj; Fri, 28 Aug 2020 18:07:41 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 28 Aug 2020 18:07:40 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id C65066029BA2; Fri, 28 Aug 2020 12:07:39 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id BDEEE669F1; Fri, 28 Aug 2020 12:07:39 -0400 (EDT) Date: Fri, 28 Aug 2020 12:07:39 -0400 (EDT) From: Paul Wouters To: Michael Richardson cc: "ipsec@ietf.org WG" In-Reply-To: <9856.1598554487@localhost> Message-ID: References: <9856.1598554487@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Question on RFC 5723 Session Resumption 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, 28 Aug 2020 16:07:47 -0000 On Thu, 27 Aug 2020, Michael Richardson wrote: > Paul Wouters wrote: > > Or update the RFC with a clarification that delete's are allowed, but > > that the server who deleted a state, upon getting a ticket MUST check: > > > - It's configuration is unchanged from when the ticket was issued (we do that) > > - The ticket's issue time plus the configuration's lifetime is not in > > the past > > - The IKE SA should not have been rekeyed [tricky without keeping > > state] > > If the ticket was issued at time A (which is in the ticket), and the IKE SA > rekey time is intervals of time B, then had the SA been active alive at time > A+B, it would have been rekeyed, right? > So, if the current time is > A+B, then the IKE SA should have been rekeyed? Yes, so that part is not the problem. > But, you alude to it requiring state, so there must be something I don't understand. We added a suspend commend, but since that deleted states on the initiator, it ended up sending delete's to the server. The server deleted the IKE SAs. Now the client can resume a connection that technically was ended by Delete. This is similar to the client not sending deletes, and the server triggering its own deletes based on liveness - the client isn't going to respond to liveness probes while suspended. If the client comes back with a valid ticket within the valid expiry time, the server does not know if A) the IKE SA was already deleted and the ticket theoretically should no longer be valid or B) the server deleted the IKE SA due to liveness timeouts and the client comes back with tickets to resume this. > >> The case of a cluster of gateways is not handled by the RFC. This is > >> alluded to at the end of the Introduction. > > > that was an unfortunate easy way to not address the problem of syncing > > state between servers :) > > Can you explain what the problem is if the ticket is used more than once > (with different gateways) within the time B? So this indeed is the important question for all of these cases. What is the harm? Because why does the RFC state that deleted IKE SAs should not be resumed? We are re-using an SK_d, but does that influence the amount of crypto done under an IKE SA (FIPS issue)? The livetimes would already be covered by the above - just don't let the ticket be valid for longer than the creation time plus rekey time. It would be really nice if we can keep the server side to need to require zero state. If we ignore those two issues mentioned, we can do that. Paul From nobody Fri Aug 28 13:42:30 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 ADFFC3A0BEB for ; Fri, 28 Aug 2020 13:42:27 -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 AB-1iUrbyB-2 for ; Fri, 28 Aug 2020 13:42:21 -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 9AE663A0BDF for ; Fri, 28 Aug 2020 13:42:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 2AFB5389DE; Fri, 28 Aug 2020 16:21:20 -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 v8Dnzi4VF11P; Fri, 28 Aug 2020 16:21:19 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D66F5389DC; Fri, 28 Aug 2020 16:21:18 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 84A4CB3; Fri, 28 Aug 2020 16:42:18 -0400 (EDT) From: Michael Richardson To: Paul Wouters , "ipsec\@ietf.org WG" In-Reply-To: References: <9856.1598554487@localhost> 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] Question on RFC 5723 Session Resumption 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, 28 Aug 2020 20:42:29 -0000 --=-=-= Content-Type: text/plain Paul Wouters wrote: >> Paul Wouters wrote: >> > Or update the RFC with a clarification that delete's are allowed, but >> > that the server who deleted a state, upon getting a ticket MUST check: >> >> > - It's configuration is unchanged from when the ticket was issued (we do that) >> > - The ticket's issue time plus the configuration's lifetime is not in >> > the past >> > - The IKE SA should not have been rekeyed [tricky without keeping >> > state] >> >> If the ticket was issued at time A (which is in the ticket), and the IKE SA >> rekey time is intervals of time B, then had the SA been active alive at time >> A+B, it would have been rekeyed, right? >> So, if the current time is > A+B, then the IKE SA should have been rekeyed? > Yes, so that part is not the problem. >> But, you alude to it requiring state, so there must be something I don't understand. > We added a suspend commend, but since that deleted states on the > initiator, it ended up sending delete's to the server. The server > deleted the IKE SAs. Now the client can resume a connection that > technically was ended by Delete. It seems that either the client shouldn't send deletes, or: > If the client comes back with a valid ticket within the valid expiry > time, the server does not know if A) the IKE SA was already deleted > and the ticket theoretically should no longer be valid or B) the server > deleted the IKE SA due to liveness timeouts and the client comes back > with tickets to resume this. the server should behave the same way regardless of who deleted the SA. >> >> The case of a cluster of gateways is not handled by the RFC. This is >> >> alluded to at the end of the Introduction. >> >> > that was an unfortunate easy way to not address the problem of syncing >> > state between servers :) >> >> Can you explain what the problem is if the ticket is used more than once >> (with different gateways) within the time B? > So this indeed is the important question for all of these cases. What is > the harm? Because why does the RFC state that deleted IKE SAs should not > be resumed? I think that maybe the intention was that IKE SAs deleted by the server due to operator action should never be resumed. Because the user changed their password, or their 2FA was compromised, or ... Maybe the state-lite way is that the identity that involved in the deleted state is marked as needing re-authentication. > We are re-using an SK_d, but does that influence the amount of crypto > done under an IKE SA (FIPS issue)? The livetimes would already be > covered by the above - just don't let the ticket be valid for longer > than the creation time plus rekey time. > It would be really nice if we can keep the server side to need to > require zero state. If we ignore those two issues mentioned, we can > do that. I agree. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9JbCoACgkQgItw+93Q 3WXaLQf/U5J25pZLm2wGJ9IZfXua50A4d8YZrx87VJta4AugQPA7Glz+6hx/Qkvi WYfgYXYzvjofk5JjygFA0b8mNsumYi5sBEQAZVfWLBwsXPTJrkMc0DcNvZ9IowOe p1DbhLCqju6ehX2HupSmzgcrJrP5xLhJ9CT7lCKZfWjrVXS00dXZDHlXb7nC9xcU FnSlo3nXVxg61L/Xs1NzqxYOI/pTj77ClWjnYmzmHG+WSNImNCB42Ph75GOpR7pF boUTxjWN1XWyz2WDkFsgPdO1u1jax5dfIRYxtY3rsq+VUQOmc3K/xG6HIK8axJT3 buaoLq7GI9KTSMhqR1uU1PLzwGQmxQ== =+bNu -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Aug 29 09:40:37 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 837AD3A0CF3 for ; Sat, 29 Aug 2020 09:40:35 -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 BeHUbse6Q4nH for ; Sat, 29 Aug 2020 09:40:33 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93B3C3A0CEF for ; Sat, 29 Aug 2020 09:40:33 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4Bf2JY5V5wz7V8; Sat, 29 Aug 2020 18:40:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1598719229; bh=fKwYcEbIlLHwx3W1TVgSVh3/4EsiU3PdoUN7/TGMUDs=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Qcux4gfSXKqAKzIbkHmyCCoF/iquyCl13pGnUL7iMNFxsAhI23dpxF1gOdIOkEXb4 oteAI/QtRcmNeucVlCwCZVFYGHyeDuO4lvRcwk0B9g1uNlrAvjyYiPnl3IEykjyHC2 kQe4zFUn0b0mtL5NH1Scy/S50Dwk2z64THY+ffp0= 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 EupMmqHgdc3R; Sat, 29 Aug 2020 18:40:28 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sat, 29 Aug 2020 18:40:28 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 704F36029BA2; Sat, 29 Aug 2020 12:40:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 67F0C669F1; Sat, 29 Aug 2020 12:40:27 -0400 (EDT) Date: Sat, 29 Aug 2020 12:40:27 -0400 (EDT) From: Paul Wouters To: Michael Richardson cc: "ipsec@ietf.org WG" In-Reply-To: <29645.1598647338@localhost> Message-ID: References: <9856.1598554487@localhost> <29645.1598647338@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Question on RFC 5723 Session Resumption 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, 29 Aug 2020 16:40:36 -0000 On Fri, 28 Aug 2020, Michael Richardson wrote: > > We added a suspend commend, but since that deleted states on the > > initiator, it ended up sending delete's to the server. The server > > deleted the IKE SAs. Now the client can resume a connection that > > technically was ended by Delete. > > It seems that either the client shouldn't send deletes, or: But not sending a delete will just result in the server sending liveness probes and deleting the client shortly after the client suspends quietly. If you want IKE Resume to work in the real world with Liveness, you basically have to ignore that the client and server delete the SA. > > If the client comes back with a valid ticket within the valid expiry > > time, the server does not know if A) the IKE SA was already deleted > > and the ticket theoretically should no longer be valid or B) the server > > deleted the IKE SA due to liveness timeouts and the client comes back > > with tickets to resume this. > > the server should behave the same way regardless of who deleted the SA. Then IKE Resume as an RFC can simply never work. No connection could ever be resumed. > I think that maybe the intention was that IKE SAs deleted by the server due to > operator action should never be resumed. Because the user changed their > password, or their 2FA was compromised, or ... That is all covered by the lifetime of the session ticket. The ike lifetime timeout (or rather, the re-authentication timeout) should be set and honoured - whether the connection is active or suspended. So as long as the server doesn't issue ticket lifetimes beyond the re-auth lifetime - everything is good. > Maybe the state-lite way is that the identity that involved in the deleted > state is marked as needing re-authentication. That information is in the encrypted ticket by way of ticket lifetime. No need for the server to keep state or state-lite. > > It would be really nice if we can keep the server side to need to > > require zero state. If we ignore those two issues mentioned, we can > > do that. > > I agree. Another approach is to add a notify to MOBIKE to tell the server to disable liveness probes, allowing the client to go to sleep without fear or losing the state on the server. It can then also sleep for some time and come back up with an MOBIKE update message. It wouldn't allow the server to delete the state but it does allow the client to go to extended periods of sleep without fear of not being able to continue with the existing Sa. Paul From nobody Sun Aug 30 19:10:52 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C655F3A0CA2 for ; Sun, 30 Aug 2020 19:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 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.948, 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 WJL-LZQAN8sy for ; Sun, 30 Aug 2020 19:10:48 -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 8F4AF3A0C9D for ; Sun, 30 Aug 2020 19:10:48 -0700 (PDT) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 19B741B00332; Mon, 31 Aug 2020 05:10:46 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1598839846; 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=apCg53+ZvFK/Ub9UrO3/TpkMV0Pq9dAHo6VB77hBzfU=; b=r6Uy/LgAWhViC0rgo6DPXsmvjlnV9x0HxoAhkdItJNnCmElFEg5jdeFUGIDUTNg0oDQUr/ Id0nsv1NdFsWO0POwbEoN4UNlCd84YEVmM15eicIU+wWo2iOAIEi0FZWR1u10I2DxK97gx BI/b2hdZH+E7UO8xFa7WYm7AwCuoTA5zqHE+azOUy/MEznIldVXRmwbG1EqRHYZdnkio/A pHeZQGStez3LVWsVTtHuTuePfR3zOiqCFIBqPMJLrXDrj5Y2vPS/aukCODZeDbrngPGawV t/HDBTV77vQJHCoXY7Tzm9qLQdnJ0dtu/rQG4TO5YjFwhaHBrJCXllZmIPpBkg== Received: by fireball.acr.fi (Postfix, from userid 15204) id B860D25C1565; Mon, 31 Aug 2020 05:10:45 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24396.23589.701449.658566@fireball.acr.fi> Date: Mon, 31 Aug 2020 05:10:45 +0300 From: Tero Kivinen To: Michael Richardson Cc: Paul Wouters , "ipsec\@ietf.org WG" In-Reply-To: <29645.1598647338@localhost> References: <9856.1598554487@localhost> <29645.1598647338@localhost> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 10 min X-Total-Time: 9 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1598839846; 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=apCg53+ZvFK/Ub9UrO3/TpkMV0Pq9dAHo6VB77hBzfU=; b=U0/EhIRlJTDtuP68vy1X1IWrS01ueE0N/ZRXuXYrjdQN+FZwPP9fuOPg64T1jY6REavKVk 0vmWEgD4dXYOS2MEpLd+55VQty4Hx38lpIz0raZ3b5cMPH+/swNBNCPvzWDzQKUU7PQ5rW l04eW8Qhd1rhAvsW3/FNe1pbjOq16BhTM3ZWCYqFspTE8PemRMi8JGpcpCU8DK+tfCqS72 M/3PqbvF2SDWrK9uow2SLBUp02qH3b2jX+FejD7zE3U5vT0YpCfjCIwBQLgVWcRuSAMGdM B1/i+PM3/6Orr3Czw8SBI5wd2d4xx+Bm4zNATICpGhIYvV1kLgMo0P6WMALVoA== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1598839846; a=rsa-sha256; cv=none; b=D1wCOb+gfp4GUnX5Am0Ium38oK/cmCxGZyAgu9Se+MpAoUFplCdX+1dNxxgDKMaHdJ9rOW HI62VLD+9+guhmxf9YYMV70zFB8LUBw07eGdVKQ99vZ2rSToN+dskokI8e6Qx4nAXLuGtp zcDr+P+zxRhu/j8f6fhYZT5r7SPMi1RfCNx+tuzXg79PCRHriArkxJ2XhXXTUEJ0pwi0F6 tqD118hbrqBZdHRsWalGLpkOq/yltjrwFTtJXcxfOHn1Fm9B7l1faQE+KoyRpCQePbn1gY GC03M/cB4pGkK9WfxBWzVTNPBn24wj7rplhkw7TapZ535yGSyIZsKkOcMc5EKg== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [IPsec] Question on RFC 5723 Session Resumption 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, 31 Aug 2020 02:10:51 -0000 Michael Richardson writes: > > We added a suspend commend, but since that deleted states on the > > initiator, it ended up sending delete's to the server. The server > > deleted the IKE SAs. Now the client can resume a connection that > > technically was ended by Delete. > > It seems that either the client shouldn't send deletes, or: I think the original idea is that if the client or server send explict delete, that is supposed to mean that IKE SA is deleted, and all information about it should be deleted, including resumption. > > If the client comes back with a valid ticket within the valid expiry > > time, the server does not know if A) the IKE SA was already deleted > > and the ticket theoretically should no longer be valid or B) the server > > deleted the IKE SA due to liveness timeouts and the client comes back > > with tickets to resume this. > > the server should behave the same way regardless of who deleted the SA. If the server deletes the IKE SA, because of liveness failure, that is not explicit delete, i.e. not something that happened based on the adminstrative action or similar, but instead it could be just temporary failure in the network. So if the server deletes IKE SA because of livenss check failures it should not mean that resumption state or the IKE SA is permanently deleted. > >> >> The case of a cluster of gateways is not handled by the RFC. This is > >> >> alluded to at the end of the Introduction. > >> > >> > that was an unfortunate easy way to not address the problem of syncing > >> > state between servers :) > >> > >> Can you explain what the problem is if the ticket is used more than once > >> (with different gateways) within the time B? > > > So this indeed is the important question for all of these cases. What is > > the harm? Because why does the RFC state that deleted IKE SAs should not > > be resumed? > > I think that maybe the intention was that IKE SAs deleted by the server due to > operator action should never be resumed. Because the user changed their > password, or their 2FA was compromised, or ... > Maybe the state-lite way is that the identity that involved in the deleted > state is marked as needing re-authentication. This is what I think the RFC tries to say. I.e., if either end explictly did adminstrative action to delete the IKE SA, then it should not be possible to do resumption to it. Of course if the user crendentials were compromised or re-authentication is required that means that the configuration of the server has changed for that user, and then ticket should be invalid because the configuration is different. Normally the ticket is encrypted with key that is changed every time the server configuration changes, which means changing the server configuration will invalidate all tickets. If this is not wanted for change which only affects certain user, then ticket should contain user identification number or similar, and the configuration serial number for that user, and every time something changes in the user configuration which requires revoking outstanding tickets, the configuration serial number for that user is incremented. If client tries to use ticket which has wrong configuration serial number for user, then server will simply reject that ticket. Anyways server or client should NOT invalidate tickets just because it deleted the IKE SA because of liveness failures. -- kivinen@iki.fi From nobody Sun Aug 30 19:16: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 2D4E63A0CA5 for ; Sun, 30 Aug 2020 19:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 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.948, 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 Kc21vzgvdifV for ; Sun, 30 Aug 2020 19:16:52 -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 4CD963A0CA4 for ; Sun, 30 Aug 2020 19:16:51 -0700 (PDT) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 6F0811B00332; Mon, 31 Aug 2020 05:16:49 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1598840209; 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=D1ykEIvLqj4Q7HtA3yH2Cc03zxOX4nIq+fwvcjiFtno=; b=Kyx2X6PEhnligvoYhkOHIUbgct4LKTn3XJuQ9aY3NCGHRw78GKDRneXQAUgrMmD7ZVtg4k ukzRsjrHCvakVApzPh7NS7SO8CE29ZYa1CTq8Mded/cZyZQ25um+cgKahROKBDQ91VQFvb LcbM75vpFlNqp/hUj03lI4gIICTuXhvOE6XooY/ozGDbqh6mBR2hLmrbZrLnb1dCKkfgWT //PwDw80epdz1XzRIfpmPHQUiLruzopnN6hfxftUGyQj9oYlwS+ZqYa3syklm8aHYQ71se ZZkY9f7Mi2Z1QxOTxQAZOIbpub8U6+XZ0DvAAC5bUJ4yXVmCDXHSDnSx0t5lkQ== Received: by fireball.acr.fi (Postfix, from userid 15204) id E9BBF25C1565; Mon, 31 Aug 2020 05:16:48 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24396.23952.909994.886850@fireball.acr.fi> Date: Mon, 31 Aug 2020 05:16:48 +0300 From: Tero Kivinen To: Paul Wouters Cc: Michael Richardson , "ipsec\@ietf.org WG" In-Reply-To: References: <9856.1598554487@localhost> <29645.1598647338@localhost> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 5 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1598840209; 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=D1ykEIvLqj4Q7HtA3yH2Cc03zxOX4nIq+fwvcjiFtno=; b=M/VdJop1tnP394jxiOI1aKL4qwFcNQp81QEUYzSZFjNd+NOZCKTuqZfE1QoCCHgKCUkz9j O3Hi+15E5UPcPJkEAkL41n4xFutSxtgA64EZ26g9GI+bpei45+7kFo77R+2MK3eOB2h/Vx d/MxWhhKxb2kwU2spNtb3O83U6lOLM/Wt/97tjKcn25ddQ/17Am19fcZkUoFSELaZfNo4z j7Pa2DXqjNgUhqV98r7k5Q6P3qCl5FRcnvNrYD06QCR9gZ+yrI/JnquJ0nnapHE4XnMEfn 4RmqXD6vrmK89ALrbv+6UOVHd8cqFz8bRl9hXXKyxMjVWCgwPG22z/oLpmUnng== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1598840209; a=rsa-sha256; cv=none; b=CPRxVYGYWRnhilZ3fOC6vvXIineVOPDojmF2gfzzd2+7H4u/IeMCiWbmy7nbuQJHTY40f3 o8ux+oI5pcSlLxUu6uA2FMk/3omyLnBbp2fFH/sIhl8A4r2IEAiewJerFsA2yh8EpfJ8YN mN+8sWKXeNmRi5uQt8IJ1NsVBTQbOoSFKf2usT/lv8pYcZJek4byvx46DFuLp1o5V5jv/+ SZzZ9Fll4pKHjeff2vpc6r4mMqg4FO4v2VsXsY2PCxPX2X1qX6R24rXAPGF8MWFig0k7uz TrhwqKd+yWoLHgtmvWct141c15spwtzvNNbcPRnoGqMUbWi2fhGm55faIhaDpg== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [IPsec] Question on RFC 5723 Session Resumption 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, 31 Aug 2020 02:16:54 -0000 Paul Wouters writes: > On Fri, 28 Aug 2020, Michael Richardson wrote: > > > > We added a suspend commend, but since that deleted states on the > > > initiator, it ended up sending delete's to the server. The server > > > deleted the IKE SAs. Now the client can resume a connection that > > > technically was ended by Delete. > > > > It seems that either the client shouldn't send deletes, or: > > But not sending a delete will just result in the server sending liveness > probes and deleting the client shortly after the client suspends > quietly. If you want IKE Resume to work in the real world with Liveness, > you basically have to ignore that the client and server delete the SA. That should not matter, the server should not invalidate tickets even if there is liveness failures, as if it does that every time there is transient network failure the resumption is useless. > > > It would be really nice if we can keep the server side to need to > > > require zero state. If we ignore those two issues mentioned, we can > > > do that. > > > > I agree. > > Another approach is to add a notify to MOBIKE to tell the server to > disable liveness probes, allowing the client to go to sleep without > fear or losing the state on the server. It can then also sleep for > some time and come back up with an MOBIKE update message. It wouldn't > allow the server to delete the state but it does allow the client to > go to extended periods of sleep without fear of not being able to > continue with the existing Sa. At one point I did propose an option for MOBIKE to send address update without any addresses, i.e., saying that I will go to sleep so I will not have any addresses you can use to connect to me, do not call me, I will call you when I am back... If I remember right people considered it too complex, and this was not accepted even when it is described in the RFC4621 Section 5.4: ---------------------------------------------------------------------- 5.4. Zero Address Set Functionality One of the features that is potentially useful is for the peer to announce that it will now disconnect for some time, i.e., it will not be reachable at all. For instance, a laptop might go to suspend mode. In this case, it could send address notification with zero new addresses, which would mean that it will not have any valid addresses anymore. The responder would then acknowledge that notification and could then temporarily disable all SAs and therefore stop sending traffic. If any of the SAs get any packets, they are simply dropped. This could also include some kind of ACK spoofing to keep the TCP/IP sessions alive (or simply setting the TCP/IP keepalives and timeouts large enough not to cause problems), or it could simply be left to the applications, e.g., allow TCP/IP sessions to notice if the link is broken. The local policy could then indicate how long the peer should allow remote peers to remain disconnected. From a technical point of view, this would provide following two features: o There is no need to transmit IPsec data traffic. IPsec-protected data can be dropped, which saves bandwidth. This does not provide a functional benefit, i.e., nothing breaks if this feature is not provided. o MOBIKE signaling messages are also ignored. The IKE SA must not be deleted, and the suspend functionality (realized with the zero address set) may require the IKE SA to be tagged with a lifetime value since the IKE SA should not be kept alive for an undefined period of time. Note that IKEv2 does not require that the IKE SA has a lifetime associated with it. In order to prevent the IKE SA from being deleted, the dead-peer detection mechanism needs to be suspended as well. Due to its complexity and no clear requirement for it, it was decided that MOBIKE does not support this feature. -- kivinen@iki.fi From nobody Sun Aug 30 19:42:16 2020 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCDF3A0CE4 for ; Sun, 30 Aug 2020 19:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ci95_9VLv2A9 for ; Sun, 30 Aug 2020 19:42:12 -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 737F73A0CE3 for ; Sun, 30 Aug 2020 19:42:12 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4BfvcL44BDz3DG; Mon, 31 Aug 2020 04:42:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1598841730; bh=TjtKrX7uu+TvoVzio/o22lNCvhDdJ7dVyH7xrxHahB0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=EM9mKHEnVta/OxUBovlM5ZK9Esoa1b3EbIoqVrI5W4Yaow50I/AFVhWvkJbjPAVsT 4Hb5jbWVam8Wb3Vj8O0Dlgtbrc9yIR7U92ccRNb/Wp7tBHx8o1qVCPymywEUfTVjag FRowxwzyqEr+lLLkUU+LF+zZGVmwLHrupJheNN2Y= 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 ToSV597qknAb; Mon, 31 Aug 2020 04:42:09 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 31 Aug 2020 04:42:09 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id A83156029BA6; Sun, 30 Aug 2020 22:42:07 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9D08166A7B; Sun, 30 Aug 2020 22:42:07 -0400 (EDT) Date: Sun, 30 Aug 2020 22:42:07 -0400 (EDT) From: Paul Wouters To: Tero Kivinen , nupur202000@gmail.com cc: "ipsec@ietf.org WG" In-Reply-To: <24396.23952.909994.886850@fireball.acr.fi> Message-ID: References: <9856.1598554487@localhost> <29645.1598647338@localhost> <24396.23952.909994.886850@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Question on RFC 5723 Session Resumption 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, 31 Aug 2020 02:42:14 -0000 On Mon, 31 Aug 2020, Tero Kivinen wrote: > That should not matter, the server should not invalidate tickets even > if there is liveness failures, as if it does that every time there is > transient network failure the resumption is useless. I agree, but that is not what the RFC says. Perhaps this would qualify for an Errata ? > At one point I did propose an option for MOBIKE to send address update > without any addresses, i.e., saying that I will go to sleep so I will > not have any addresses you can use to connect to me, do not call me, I > will call you when I am back... > > If I remember right people considered it too complex, and this was not > accepted But it is possible, sort of. The client just sleeps and upon wake up sends the UPDATE without any addresses specified and the responder will update to the address and port of the IKE header (after packet was authenticated). But you are right in that with MOBIKE, we have no way of saying "please suspend any liveness tests - I will be out of the office". I do think overall it would have been better to have 1 solution instead of 2. But I think with supporting both, things can work the way we want. For unexpected network outages we can switch interface using MOBIKE. Like phone losing wifi briefly in the elevator. For expected downtime, eg "phone is going to sleep mode" we can use RESUME to reconnect. Resume does take two roundtrips over mobike taking one. So perhaps it would still be nice to have the "out of office notify" to instruct the server to disable liveness so MOBIKE can be used instead of RESUME. However, that does take more resources on the server. But looking at realy busy servers now - it is a stream of (re)connecting clients, so I'll take any solution even if it needs state as it is less work than all these new DH exchanges. Paul From nobody Mon Aug 31 10:34: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 EA5293A0D2C for ; Mon, 31 Aug 2020 10:34:52 -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 2-zhYuCwyhvQ for ; Mon, 31 Aug 2020 10:34:51 -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 37F393A0D32 for ; Mon, 31 Aug 2020 10:34:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 45AFB389C5 for ; Mon, 31 Aug 2020 13:13:45 -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 PYx05ohDAZeF for ; Mon, 31 Aug 2020 13:13:43 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6C66B389C4 for ; Mon, 31 Aug 2020 13:13:43 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 04EC7476 for ; Mon, 31 Aug 2020 13:34:46 -0400 (EDT) From: Michael Richardson To: "ipsec\@ietf.org WG" In-Reply-To: <24396.23589.701449.658566@fireball.acr.fi> References: <9856.1598554487@localhost> <29645.1598647338@localhost> <24396.23589.701449.658566@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] Question on RFC 5723 Session Resumption 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, 31 Aug 2020 17:34:53 -0000 --=-=-= Content-Type: text/plain Tero Kivinen wrote: > Normally the ticket is encrypted with key that is changed every time > the server configuration changes, which means changing the server > configuration will invalidate all tickets. This is probably a rather bad thing. > If this is not wanted for > change which only affects certain user, then ticket should contain > user identification number or similar, and the configuration serial > number for that user, and every time something changes in the user > configuration which requires revoking outstanding tickets, the > configuration serial number for that user is incremented. If client > tries to use ticket which has wrong configuration serial number for > user, then server will simply reject that ticket. In many cases there is a single configuration "template" which applies to all users who authenticate with a certificate from a certain CA, or with a login matching some pattern. In order to store the configuration serial number, on a per-user basis, then some state is created a per-user basis. This does not sound like a horrible thing to me, but it is probably something new. It seems that you see that deleting the CHILD (IPsec) SA on failure of a liveness check is enough savings. I don't know how universal this thought process is. Certainly, if one has limited hardware for IPsec slots, then it conserves the expensive bit. If one keeps the parent SA around, then one has some state in which to store per-user data. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9NNLUACgkQgItw+93Q 3WXKxwf/SK19VGuXQC4yx2QUzfd8zcHtxfPgqNkGpA/vrTLJOzuJm1QpgZNIcq14 I7aEITfUADmmJs8fPWvMrqUiYnjXmIROlEnMihl9jwsKnRnWeERaD6JAzOJvzyCA rcqgZJ0Lrck/NDE2IBspvzxudme10WnOnPzbWBXlUOvjke97WdFebsl9mVxS8Ekz k9v/6mB+ikLWc5pfO/zrF0VhrLvW+h7zh/g/kLMwB+A9vehUyHtJp2flfpUmjvwh OL+dj6nboKBBRo/SruxwkimKQ6/kYf2ZX2/EEIwtnodX0x8Ylb3fpyhhZWB8WCQ9 ab/F0QZRkNfHgcOSvaswXQhXd69DSQ== =OU5G -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 31 15:23:42 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 960123A1995 for ; Mon, 31 Aug 2020 15:23:40 -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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 lEu2R-o12TOZ for ; Mon, 31 Aug 2020 15:23:39 -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 7C0C53A1990 for ; Mon, 31 Aug 2020 15:23:39 -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 07VMNWUN019659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 31 Aug 2020 18:23:35 -0400 Date: Mon, 31 Aug 2020 15:23:31 -0700 From: Benjamin Kaduk To: Paul Wouters Cc: Tero Kivinen , nupur202000@gmail.com, "ipsec@ietf.org WG" Message-ID: <20200831222331.GO16914@kduck.mit.edu> References: <9856.1598554487@localhost> <29645.1598647338@localhost> <24396.23952.909994.886850@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [IPsec] Question on RFC 5723 Session Resumption 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, 31 Aug 2020 22:23:41 -0000 On Sun, Aug 30, 2020 at 10:42:07PM -0400, Paul Wouters wrote: > On Mon, 31 Aug 2020, Tero Kivinen wrote: > > > That should not matter, the server should not invalidate tickets even > > if there is liveness failures, as if it does that every time there is > > transient network failure the resumption is useless. > > I agree, but that is not what the RFC says. Perhaps this would qualify > for an Errata ? I think an Errata Report would be appropriate for this topic. Given that we are still discussing the details, I suggest to iterate on the OLD/NEW text on the list before actually submitting the report, though. Thanks, Ben