From nobody Thu Apr 1 06:36:28 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8CC3A11E8 for ; Thu, 1 Apr 2021 06:36: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 jG2NleBt9aiT for ; Thu, 1 Apr 2021 06:36:22 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [62.96.220.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 696963A11E6 for ; Thu, 1 Apr 2021 06:36:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 93611205A4; Thu, 1 Apr 2021 15:36:18 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JScmw1_lKLx; Thu, 1 Apr 2021 15:36:17 +0200 (CEST) Received: from cas-essen-01.secunet.de (unknown [10.53.40.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by a.mx.secunet.com (Postfix) with ESMTPS id AE1CF20512; Thu, 1 Apr 2021 15:36:17 +0200 (CEST) Received: from mbx-essen-01.secunet.de (10.53.40.197) by cas-essen-01.secunet.de (10.53.40.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Thu, 1 Apr 2021 15:36:17 +0200 Received: from moon.secunet.de (172.18.26.121) by mbx-essen-01.secunet.de (10.53.40.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Thu, 1 Apr 2021 15:36:17 +0200 Date: Thu, 1 Apr 2021 15:36:15 +0200 From: Antony Antony To: "Bottorff, Paul" CC: "antony.antony@secunet.com" , IPsec Message-ID: <20210401133615.GB27893@moon.secunet.de> Reply-To: References: <20210331103220.GA21137@moon.secunet.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: Precedence: first-class Priority: normal Organization: secunet User-Agent: Mutt/1.10.1 (2018-07-13) X-ClientProxiedBy: cas-essen-02.secunet.de (10.53.40.202) To mbx-essen-01.secunet.de (10.53.40.197) X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Archived-At: Subject: Re: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2021 13:36:28 -0000 On Wed, Mar 31, 2021 at 23:38:01 +0000, Bottorff, Paul wrote: > Hi Antony: > > Below, > > Cheers, > > Paul > > > > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Antony Antony > Sent: Wednesday, March 31, 2021 3:32 AM > To: Bottorff, Paul ; IPsec > Cc: antony.antony@secunet.com > Subject: Re: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07 > > Hi, > > This is an interesting draft. I would love to see a generic solution for network paths and receiver use cases, such as RSS. > > PB>> Can you explain your use case for RSS a little more? I'd guess you are looking at LB around the RSS queues to get better distribution for the decodes. > << We are using muliple SAs, with identical Traffic Selectors, to load balance IPsec traffic between IPsec peers. https://datatracker.ietf.org/doc/draft-pwouters-multi-sa-performance/ This should improve multi-core-cpu utilization and IPsec throughput. The receiver should distribute the flows, based on SPI, to different CPUs for decryption. Ideally the NIC should support a ntuple flow distribution using SPI. It is not yet widely supported, and also not compatible with older NICs. Now we are thinking of ESP in UDP with different source ports. Just like the draft proposed for ECMP and LAG. When implementing it I ran into issues with NAT and SAD remapping messages which update IKE. I am using strongSWAN for IKE and Linux XFRM for ESP. > The RFC3948 specifies one pair of UDP ports 4500-4500. > Both the IKE flow and the ESP in UDP flow should use the same UDP flow. > The draft seems to suggest new destination port and source ports are only for ESP? How would this change work with IKE? > May you are not intending to use IKE? PB> Our use cases use IKE, however as stated in RFC3948 ESPinUDP does not have to be PB> tied to IKE, it is just advantageous to do so for the NAT case since this allows PB> a single mapping for both at the NAT rather than two mappings. PB> I've wondered why we could not use the RFC3948 encoding for ESPinUDP, but allow PB> the source port to be chosen differently than IKE. Perhaps Xu has some thoughts on this. In my experience it would work well when there is no NAT. When there there is NAT the IKE and ESP in UDP should use same ports, otherwise IKE will get established and ESP packets could get dropped in one direction. When there is NAT it would look more like a client-to-server than a peer-to-peer. > How would the new ESP flow work when there is a NAT gateway along the path? > I ran into issues with both sides choosing different source ports. > It would cause SADB mapping changes which force changes IKE flows. One coul disable > SADB mapping changes. However, that would break real NAT changes. > PB> We are mostly interested in data centre use cases which don't have intervening NATs, PB> however I believe SD-WAN cases could have NAT and FW traversals between tunnel end PB> points. As it stands draft-xu-ipsecme-esp-in-udp-lb does not specify how the source port PB> value is determined. It seems like it could be based on a hash value within the ESP or PB> based on the SPI and IPs. I implemented a proof concept - UDP source port set to 16bit hash of out going SPI. Then it occurred to me the hash could collide with other well known UDP ports e.g. hash of an SPI or/and IP address could be 53(DNS). Some admins may not be happy to see source port 53 for ESP in UDP traffic. If you choose ephemeral source ports both sides should know the source ports otherwise SADB remap will be generated. If we disable that real NAT would break... So far I don't have a clean solution which would work with NAT and without NAT for our use case. From nobody Thu Apr 1 07:11:08 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C61B23A135E for ; Thu, 1 Apr 2021 07:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 Mhf4GBAn4W9L for ; Thu, 1 Apr 2021 07:11:01 -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 6D5423A135F for ; Thu, 1 Apr 2021 07:11:01 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4FB4pj70zJzCqt; Thu, 1 Apr 2021 16:10:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1617286253; bh=86vUaUUyCen2o8N7QePOCeaQxwjlow1eFeXILLdofkQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=sE5fqFJvyS/Ylx7MEN8zTh/yUOvY/k62uClDER8MvPT+BnyK71mSgQ88cUavbOpTZ iY0G11lmW7noRV85eP72r4AVjx1DVl9NdDIJjoh+luy7G1iw56LvaB8zEhvaQqnAdr oqqoIreTdxmyvkfXmgCzMnvlOl5NRfe+E+Fjzgw0= 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 A-KHkYpgEa-o; Thu, 1 Apr 2021 16:10:52 +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, 1 Apr 2021 16:10:52 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id AE33660299AB; Thu, 1 Apr 2021 10:10:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A55AB1259; Thu, 1 Apr 2021 10:10:51 -0400 (EDT) Date: Thu, 1 Apr 2021 10:10:51 -0400 (EDT) From: Paul Wouters To: Antony Antony cc: "Bottorff, Paul" , IPsec In-Reply-To: <20210401133615.GB27893@moon.secunet.de> Message-ID: <5851ee8a-4797-5c4b-379-fbbc2295e1bc@nohats.ca> References: <20210331103220.GA21137@moon.secunet.de> <20210401133615.GB27893@moon.secunet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2021 14:11:07 -0000 On Thu, 1 Apr 2021, Antony Antony wrote: > In my experience it would work well when there is no NAT. When there > there is NAT the IKE and ESP in UDP should use same ports, otherwise > IKE will get established and ESP packets could get dropped in one > direction. When there is NAT it would look more like a client-to-server > than a peer-to-peer. One idea could be to use MOBIKE probes (without UPDATE_SA) by the initiator behind NAT to get multiple NAT mappings? It might require kernel changes depending on how it implements NAT updates :/ > I implemented a proof concept - UDP source port set to 16bit hash of out going SPI. > Then it occurred to me the hash could collide with other well > known UDP ports e.g. hash of an SPI or/and IP address could be 53(DNS). > Some admins may not be happy to see source port 53 for ESP in UDP traffic. I seen this in the wild already with a large VPN provider blocking port 19 (chargen) and NAT gateways picking port 19 as source port. While this could be an attack to try and trigger chargen responses from a spoofed packet, I don't think it is. It might work for TCP, but not really for UDP as a DoS attack. I think in the end, sadly, we have to expect every port to be used by badly designed NAT gateways. However, it would still be a good design to keep UDP source ports in the ephemeral ranges. This also helps against local policy enforcements, such as Linux's SElinux policies. > If you choose ephemeral source ports both sides should know the source > ports otherwise SADB remap will be generated. If we disable that real NAT > would break... > So far I don't have a clean solution which would work with NAT and without NAT > for our use case. That is indeed the real problem to solve. I have to do some more testingwith MOBIKE probes on the same IP with only port differences and see if the kernel acts like these are port updates or not if it is only IKEinUDP and not ESPinUDP. Paul From nobody Thu Apr 1 15:41:02 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3B63A263F for ; Thu, 1 Apr 2021 15:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOmkm14RqBk3 for ; Thu, 1 Apr 2021 15:40:56 -0700 (PDT) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [185.185.170.37]) (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 1C5743A263C for ; Thu, 1 Apr 2021 15:40:55 -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 6522E1B002B6; Fri, 2 Apr 2021 01:40:52 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1617316852; 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=IDx7J4cwS/bnzQ8VtCxZNrySGJfA2KEh6KSbu2roFqs=; b=HOY8yIbIcvFjy5ssd570o6Wp0pds1DuNf1reGDqYpxRDBsJWQ1IZsd4+91hgDWWshKfrz/ RHvWzLUks0YKaGKD1SvoWI2nzkhCdoHfYUe/A9Mh6SnHZtLqNb3Bhy2KCedcgYCKyq9qcY YcDARv0B3fvnN2Sqqb1jcNaW823ObcdS+Uqy2ghoZTVy/1SrEzT3DhLswuypbsD8q7XmIB aYOrrg3314vvJhhBEQlxEZuy4T1m8gOUJ+0fJ+/CqNSd4QxN/OYIGcBZA6q+vMs21DJrBs LqBByJPiNxAkiv/XfD1la2zn+R23p3cFUWD2AeXxofHqXB8OIvVKxexW+2s88g== Received: by fireball.acr.fi (Postfix, from userid 15204) id 94A8625C102E; Fri, 2 Apr 2021 01:40:48 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24678.19440.553333.890224@fireball.acr.fi> Date: Fri, 2 Apr 2021 01:40:48 +0300 From: Tero Kivinen To: "Bottorff\, Paul" Cc: "antony.antony\@secunet.com" , IPsec In-Reply-To: References: <20210331103220.GA21137@moon.secunet.de> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 16 min X-Total-Time: 23 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1617316852; 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=IDx7J4cwS/bnzQ8VtCxZNrySGJfA2KEh6KSbu2roFqs=; b=P+iSLsLu4pFnlI2EXbPBNhGtZ3hr6RX+7qrVS4uvGHCpD8nOCFdt6jmKhqFNXzzPbKg03b ec1+gdBfrvudNzpEjIfpxMueEDHmgvSjwS/bBV8581Gf61/OJG4HgIgoWrnRPRI3D9u2WM Zi1Xg6t+UcwrQTUIS0maPuEfvAW4+zgGPIgu5TMFk1BAJHBvCG1NXSXG23AFK7gb0UKILh oclumv0bLIm5vRVIXBc6kZUr5XV267Srsnr5EMtV3q4WOAyVjLNr/KxadIpx47DD/cnjCP P+AuWQIo5+dy/Cjv73tifWGsiF2qAx+TVgtyVlsvJosDD4pohmNHh1kQEkivSA== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1617316852; a=rsa-sha256; cv=none; b=ZacN9rCEgvoBi4GqPejdkg3gikZyHPX78jgHuYIzWZMBrrWVpZex76WCkjfC7Z+FlU/eI7 oJ4ewqBqoEN8FWVIlw59Q9oRZprTIUtgKh36apM1Gq3hdhwuEPZ2SRzARKJpEZMMbEdLBp YOwWWRGoGkIcPF3r6pEp9FBpkaaMgGG64QY8OxGa/B+V57O6g5Bxhpoqef/2Dx0+20iLlW YwL1xqZAE7UUyD7V++15qv6FkjOg+oeKRxkJ5A+uBH/aLVgSQz7pSMmW+/96OtybydgoJS lSDwoY++6knAW+k3+uXhTHHqPLJigA10iDspwRQqFiVHUwCZCN3S0XJYMvyr/w== Archived-At: Subject: Re: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2021 22:41:00 -0000 Bottorff, Paul writes: > The RFC3948 specifies one pair of UDP ports 4500-4500. No it does not. It says you must use same ports than what you do for IKE traffic. > Both the IKE flow and the ESP in UDP flow should use the same UDP > flow. The draft seems to suggest new destination port and source > ports are only for ESP? How would this change work with IKE? May you > are not intending to use IKE? The reason NAT-T uses same ports for both ESP and IKE is to make sure that responder will know the port mapping from the IKE packets for ESP packets too. If they would use different port numbers, then responder would need to wait for first ESP packet to come in from the initiator before it can send any ESP packets back, as it would be able to know which port numbers to use for ESP traffic. Also keepalives would be needed to do for both IKE and ESP separately. > PB>>Our use cases use IKE, however as stated in RFC3948 ESPinUDP does not have to be tied to IKE, it is just advantageous to do so for the NAT case since this allows a single mapping for both at the NAT rather than two mappings. > PB>>I've wondered why we could not use the RFC3948 encoding for ESPinUDP, but allow the source port to be chosen differently than IKE. Perhaps Xu has some thoughts on this. > << As there is no way for the responder to know whether the initiator sent the packet out using source port of 4500 and then NAT changed it to port number of xxxx, or whether the initiator sent the packet out using port number of xxxx himself, the RFC7296 do require that responder MUST accept incoming packets regardless of the source port, and MUST always respond back to exactly same IP and port than what was in the source packet of the request: >From the 2.11 of the RFC7296: An implementation MUST accept incoming requests even if the source port is not 500 or 4500, and MUST respond to the address and port from which the request was received. It MUST specify the address and port at which the request was received as the source address and port in the response. There is text in 2.23 of the RFC7296 which do say: For this reason, even though IKE packets MUST be sent to and from UDP port 500 or 4500, they MUST be accepted coming from any port and responses MUST be sent to the port from whence they came. Which is bit funny, as the "even though" claims that IKE packets must be sent to and from UDP port 500 or 4500, and there is no such claim anywhere else in the RFC7296. I think it was supposed to say that "even though IKE packets are normally sent ...", as this is not correct place to make this kind of new requirement. So making IKE implementation which uses some other source port than 500 or 4500 is common way to force NAT-T traversal and UDP encapsulation on, and in that way allow user mode IKE + IPsec to be implemented without affecting the in kernel version of the IPsec in the host. I.e., user mode application wanting to use IPsec in usermode without affecting host IPsec in any ways can use any random port as source port and port 4500 as the destination port, and make sure that NAT_DETECTION_SOURCE_IP does not match, so responder will enable udp encapsulation. The responder MUST work even with that setup, so there is no reason why there should be requirement for the oritinal sender should be mandated to use source port 4500... > PB>>We are mostly interested in data centre use cases which don't have intervening NATs, however I believe SD-WAN cases could have NAT and FW traversals between tunnel end points. As it stands draft-xu-ipsecme-esp-in-udp-lb does not specify how the source port value is determined. It seems like it could be based on a hash value within the ESP or based on the SPI and IPs. > << > > Should both sides use the same source port? For the load balancing I think it is enough for just one of the ports to be different, thus initiator could simply allocate n random source port numbers, and initiate IKE from each of them to responder, and then create SAs for each of them separately, thus allowing load balancing using UDP encapsulation using existing hardware. The real issue is that if you do not want to create n separate IKE SAs, then you need to do something special, and there are other things that needs to be considered then. -- kivinen@iki.fi From nobody Thu Apr 1 18:41:22 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC2D3A2BDA; Thu, 1 Apr 2021 18:41:15 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 r1Dgt7tOvbg9; Thu, 1 Apr 2021 18:41:09 -0700 (PDT) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 115973A2BD8; Thu, 1 Apr 2021 18:41:08 -0700 (PDT) Received: by mail-vs1-xe2d.google.com with SMTP id u29so2129882vsi.12; Thu, 01 Apr 2021 18:41:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wMcoEbAIGvYdLY2E8bPu7Tr9qbsPEDiWX5lOtFg3YqM=; b=qn1HRHSK3T3lKJLNjN03fqsHLoshq9LFiboqQInhqoxs9VanN7hOZmOkHPTWS0unhY w42JB4to237EhU6Ii7ZIyQolc8OtQY6rbN7b11HWu84HE9/R6cdU5kqL6JImFfUe5QML ypRoDJwLFYvbC/G+hNNDop8nSXk3g8BDrWVXlki3QDjjTW1Vi9A7t+KRFgZwAh85sT8X QYCcKOL3mv8gbQ/kSsDq3OT+8aJuFpP/7KVmwObaRomirki0EJNiU6efFENYWytYB23o 0gOfzYCahzhpwfOkUzuKDhrhIm1MfXVxIF+uer8Q7iDXkUM4Ch+TEjSUAiOWZEepZH2z A3eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wMcoEbAIGvYdLY2E8bPu7Tr9qbsPEDiWX5lOtFg3YqM=; b=k154Pe4SJ/NVuzDcuCJVtuuqUOKxZfAOPQmAbl4MJtBp9IbUEU0BlSUckgKZlGcMfL DGrdAD2a757L4avYOT4aiXRlYiSXz/DigXv8v1G3ugh4Wq3tusu92x0pvqRPB0rmntAy bTUsv1pHipbaN4nL5q08m0JEGiMYRN9Yy17xbAv60BaLkEH/9nCMnp5KECBgcXyYVkKv MWA7xNF1tNHnf1K8XW8FjLdT4mdH+DSrifGvAADVqwo6Kwmc/oDOW/uiB4pfRP7jJ9ML aTk4bRgANkMIKSq0diNu45TXIehe3i83nB3u381NqbQxY+YNRUYeCSeK1Em5MuZndpTn B0aQ== X-Gm-Message-State: AOAM531exOOOWkzPlj4Bp3sUcXpaNM5Yt0o4LHz6x1nlTKjIRxtt9NDh sByZsHcNJx4uefIDKzxtWkeAKRJKnpVVNOhuWtA= X-Google-Smtp-Source: ABdhPJxuyBU+SlqxcTaeGNcRCCpF1lDUygqqPZm9M4sQaTPDsOANPtO91DdnFU9jPs4SBDFv2JB0ICXmVQmMbvYMCs0= X-Received: by 2002:a67:f40c:: with SMTP id p12mr7714143vsn.56.1617327666896; Thu, 01 Apr 2021 18:41:06 -0700 (PDT) MIME-Version: 1.0 References: <161680118793.27712.1491181617938861319@ietfa.amsl.com> In-Reply-To: From: Daniel Migault Date: Thu, 1 Apr 2021 21:40:55 -0400 Message-ID: To: Nancy Cam-Winget Cc: iot-directorate@ietf.org, last-call@ietf.org, draft-ietf-lwig-minimal-esp.all@ietf.org, lwip@ietf.org, IPsecME WG Content-Type: multipart/alternative; boundary="00000000000012218705bef371cf" Archived-At: Subject: Re: [IPsec] [Lwip] Iotdir last call review of draft-ietf-lwig-minimal-esp-03 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, 02 Apr 2021 01:41:16 -0000 --00000000000012218705bef371cf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Nancy, Regarding ISSUE 3, I have the impression that the concern that AES-GCM, Chacha20-Poly1305 or AES-CCM only send a 64 bit IV which suggest that only 64 bit IV can be sent with ESP. In fact the IV is not a field in ESP but is defined for each suite, as a result, ESP would be able to support any suite with larger or short IV. Then, the use of a 96 bit nonce is not uncommon, actually AES-GCM and Chacha20-Poly1305 do use 96 bit nonce and AES-CCM uses a 88 bit nonce. The nonce is formed based on a slat and the IV. Similar construction may be provided for AES-GCM-SIV if needed as far as I can see. AES-GCM-SIV is only defined as an algorithm, I also suggest to add other alternatives that have a similar goals. The current text is as follows and I think it might close the ISSUE 3. When the key is likely to be re-used across reboots, it is RECOMMENDED to consider algorithms that are nonce misuse resistant such as, for example, AES-SIV [RFC5297], AES-GCM-SIV [RFC8452] or Deoxys-II [deoxys]. Note however that currently none of them has yet been defined for ESP. I suspect the ISSUE 1 and ISSUE 2 are related to IV collision. If so it seems to me related to the collision of IV. If so I think the current proposed text for SN addresses the concerns that an algorithm should not be used beyond its limits. In addition the following text in the security consideration seems to address that concern as well: the nodes MUST ensure that keys are not used beyond their lifetime and that the appropriate use of the key remains across reboots - e.g. conditions on counters and nonces remains valid. I suspect that collision is related to the collision of IV which is only a concern when the IV needs to be unpredictable. I am tempted to think that algorithms that the properties of the IV are really part of the algorithm properties and that they cover / include into the lifetime of the keys. On the other hand, most recommended algorithms AES-GCM, AES-CCM, Chacha-Poly1305 are using IVs that just do not need to repeat, and so use counters where collision is not a concern. Of course this does not concerne collision across reboot, but I do not think these were the collisions that caused your concern. If I am correct, that probably also addresses ISSUEs 1 and ISSUE 2. I will publish the version with the current changes so reviews have the most recent editorial changes and will update from that according to your response. Again thank you for the in depth review and the many comments that already result in many clarifications - at least I think so. Yours, Daniel On Tue, Mar 30, 2021 at 10:45 PM Daniel Migault wrote= : > Hi Nancy, > > Thank you very much for your review. Please see inline my responses. I > believe all concerns raised have been addressed. I also believe the curre= nt > text addresses some concerns also raised by Paul W. > > The current version can be found here: > > https://github.com/mglt/draft-mglt-lwig-minimal-esp/pull/1/commits/fb9393= a246298e37adcf2683afa2061a40b4ed89 > > I think there are however three remaining issues that might get further > discussions. For all of these I provided a response, but I am unsure it > really addresses the three concerns below: > > ---- > ISSUE 1 > ---- > - I might challenge due to potential collision attacks that at > most, 2^32-1 packets may be sent before the SPI *must* rekey, so the SN > and how > it is used is part of the security context for the SPI/SA. I might also > challenge that a recommendation for using a rekey mechanism is warranted > because constrained devices tend to stay up for very, very, very long > periods > of time and even with an ESN there can be exhaustion :-) > > I am missing the concern. I understand the first concern is that the > current text seems to push the limit of packets being sent being determin= ed > by the SN as opposed to cryptographic properties. If my understanding is > correct, I have the current text seems clear that crypto properties are > given priorities. I suspect more guidance would be given. If that is the > case, I find it difficult as these guidances are really based on the > cryptographic algorithm and the key sizes. In any case, if I am > missing something, feel free to propose some text. > > """ > Note that the limit of messages being sent is primarily determined by the > security associated with the key rather than the SN. > The security of all data protected under a given key decreases slightly > with each message and a node MUST ensure the limit is not reached - even > though the SN would permit it. > """ > > I understand the second concern as that current text is read as rekey > mechanisms are recommended only when there is a risk the SN get exhausted= . > Our intention was to read the text as even if ESN raises the limit to an > acceptable limit, it is preferred to have a rekey mechanism. I propose th= e > following text to clarify the meaning: > > OLD: > In a constrained environment, it is likely that the implementation of a > rekey mechanism is preferred over the use of ESN. > > NEW: > Estimation of the maximum number of packets to be sent by a node is alway= s > challenging and as such should be considered cautiously as nodes could be > online for much more time than expected. > Even for constrained devices, it is RECOMMENDED to implement some rekey > mechanisms (see ). > > --- > ISSUE 2 > --- > - > Resilience to nonce reuse goes to the SN considerations as well (see my > comments for Section 4). > > --- > ISSUE 3 > --- > >> Currently RFC8452 is not cited as negotiated ciphers in RFC 8221, so >> considerations for 96bit nonce which doesn=E2=80=99t fit into the ESP he= ader, so >> while >> a general alternative not sure how you would apply it to ESP unless >> changes are >> made? > > > > This is correct that AES-GCM-SIV was not mentioned in RFC8221, and I > mentioned it as an example. Now, it seems more problematic to have an > example of a cipher suite that does not work for ESP. > I am balanced between indicating that its support is not defined with ESP > so the reader still has a reference to an example of such a cipher suite. > > I will raise this issue to the WG, but currently the text is as follows: > > """ > When the key is likely to be re-used across reboots, it is RECOMMENDED to > consider transforms that are nonce misuse > resistant such as AES-GCM-SIV for example. Note > however that AES-GCM-SIV has not yet been defined for ESP. > """ > > >> > Yours, > Daniel > > > > On Fri, Mar 26, 2021 at 7:27 PM Nancy Cam-Winget via Datatracker < > noreply@ietf.org> wrote: > >> Reviewer: Nancy Cam-Winget >> Review result: Ready with Issues >> >> General Comments >> The document flows relatively well; I expect that the editors will fix >> editorial/grammatical issues and I=E2=80=99ve noted a couple below. I di= d have >> some >> questions to some of the descriptions where I expected guidance but read >> the >> text as being more considerations so asked questions for clarification. >> >> Technical comments: >> Section 2: >> - The first paragraph speaks to other drafts defining minimal >> exchanges/operations and compression to serve IoT; >> and then states =E2=80=9CThis document describes the minimal properties = and ESP >> implementation needs to meet.=E2=80=9D Needs more clarification, is it s= o that it >> can >> interoperate with non-minimal ESP (e.g. RFC 4303 as defined) or to >> Interoperate >> given a set of constraints e.g. the minimal set to be defined in this >> document >> including RFC 7815, et al? I think it is the former but the flow of the >> paragraph makes it unclear=E2=80=A6. >> >> > > The purpose of the document is to provide guidance to build a minimal ESP > implementation that remains interoperable with the RFC4303 ESP. In additi= on > to the properties that needs to be met by a minimal ESP implementation, t= he > document also provides some guidance on how the properties may be > implemented while also meeting some constraints of specific environments. > Here is the text I propose: > > OLD: > This document describes the minimal properties and ESP implementation > needs to meet. > > > NEW: > This document describes the minimal properties an ESP implementation need= s > to meet to remain interoperable with RFC4303 ESP. > In addition, this document also provides a set of options to implement > these properties under certain constrained environments. > > > Section 3: >> - Why is it RECOMMENDED to have a randomly generated SPI? The next >> paragraph >> claims that it is not necessary, which in reading RFC 4303 is the case. >> So >> this statement seems to contradict The following paragraph that relaxes >> this >> constraint. But the rationale doesn=E2=80=99t seem to coincide; e.g. = =E2=80=9CA node >> provisioned with keys by a third party =E2=80=A6.uses a transform that d= oesn=E2=80=99t not >> needs random data=E2=80=A6=E2=80=9D Isn=E2=80=99t relevant to the SPI wh= ich is intended to be an >> Index=E2=80=A6.so better clarification of the security concerns are requ= ired. >> Perhaps >> on the relaxation, inclusion of consideration of non-reuse and uniquenes= s >> of >> the SPI to reduce replay and maybe cross SA attacks should also be >> included. >> >> > Thanks for these comments, that is helpful to clarify this section. While > SPI do not need to be random this is usually how SPI are generated. As a > result, using non random values raised a lot of discussions while the use > of random did not raise any discussions. I think that is the reason the t= wo > visions have been documented in an unbalanced way. > I agree that the text could be clearer and much more concise. I have > restructured the full section exposing what 4303 mentions regarding the > generation of the SPI, what and whay SPI are generally generated randomly > as well as why and how non random SPI may be generated. I have also adde= d > a section that groups consideration on SPI generation. I hope this is > clearer now. > > NEW: > RFC4303 does not require the SPI to be randomly generated over 32 bits. > However, this is the RECOMMENDED way to generate SPIs as it provides some > privacy benefits and avoids, for example, correlation between ESP > communications. > To randomly generate a 32 bit SPI, the node generates a random 32 bit > value, checks does not fall in the 0-255 range. > If the SPI has an acceptable value, it is used to index the inbound > session, otherwise the SPI is re-generated until an acceptable value is > found. > > However, some constrained nodes may be less concerned by the privacy > properties associated to SPIs randomly generated. > Examples of such nodes might include sensors looking to reduce their code > complexity, in which case the use of a predictive function to generate th= e > SPI might be preferred over the generation and handling of random values. > An example of such predictable function may consider the combination of a > fixed value and the memory address of the SAD structure. > For every incoming packet, the node will be able to point the SAD > structure directly from the SPI value. This avoids having a separate and > additional binding between SPI and SAD entries that is involved for every > incoming packet. > > OLD: > It is RECOMMENDED to index each inbound session with a SPI randomly > generate over 32 bits. > Upon the generation of a SPI the peer checks the SPI is not already used > and does not fall in the 0-255 range. > If the SPI has an acceptable value, it is used to index the inbound > session, otherwise the SPI is re-generated until an acceptable value is > found. > A random generation provides a stateless way to generate the SPIs, while > keeping the probability of collision between SPIs relatively low. > > However, for some constrained nodes, generating and handling 32 bit > random SPI may consume too much resource, in which case SPI can be > generated using predictable functions or end up in a using a subset of th= e > possible values for SPI. > In fact, the SPI does not necessarily need to be randomly generated. > A node provisioned with keys by a third party - e.g. that does not > generate them - and that uses a transform that does not needs random data > may not have such random generators. > However, nonrandom SPI and restricting their possible values MAY lead to > privacy and security concerns. > As a result, this alternative should be considered for devices that would > be strongly impacted by the generation of a random SPI and after > understanding the privacy and security impact of generating nonrandom > SPI. > > > - The last paragraph goes to the consideration that constrained devices m= ay >> suffer from long lag times Between breach-patch availability to actual >> deployment (or lack thereof). But that rationale, imho, Is not the >> motivation >> for predictable SPIs; unless the consideration is more that if they don= =E2=80=99t >> adhere to Appropriate key refreshes and SPI rotation that could lead to >> replay >> attacks. On the privacy front, Predictability of SPIs in particular SAs >> could >> over time help an attacker gain more information about The actual device= s >> and >> behavior. >> >> > If a device of type "A" implements ESP that takes very limited values of > SPI, an observer that monitors the traffic that observes such values will > be able to define that there is a high probability the device is of type > "A". When these devices have vulnerabilities, the observer this informati= on > may be used by the observer to infer potential vulnerabilities the device > is subject to. In my mind the observer is an attacker, so I would be > tempted to consider this as a drawback. > From your text I have the impression that the use of these non random > values for SPI may be used by an administrator to monitor potential > vulnerabilities in its network - which could be seen as a feature. This i= s > how I am reading the first sentence of your comment, but I might be missi= ng > it. > > In any case, I agree that this is not the rationale for using non random > SPIs. In my view that is more a drawback. "In addition" was intended to > raise an additional security concern which is that knowing the SPI or not > changing the SPI will ease an attacker to forge packets with a valid SPI.= I > agree with you that this is also associated with any long term ESP sessio= ns > and can be removed. > > As mentioned above, I have restructured and shortened the text and here i= s > the content of the "Considerations over SPI generation" section: > > NEW: > > SPI that are not randomly generated over 32 bits MAY lead to privacy and > security concerns. > As a result, the use of alternative designs requires careful security and > privacy reviews. > This section provides some considerations upon the adoption of alternativ= e > designs. > > > Note that SPI value is used only for inbound traffic, as such the SPI > negotiated with IKEv2 RFC7296 or RFC7815 by a peer, is the value used by > the remote peer when it sends traffic. > As SPI is only used for inbound traffic by the peer, this allows each pee= r > to manage the set of SPIs used for its inbound traffic. > Similarly, the privacy concerns associated with the generation of > nonrandom SPI is also limited to the incoming traffic. > > When alternate designs are considered, it is likely that the number of > possible SPIs will be limited. > This limit should both consider the number of inbound SAs - possibly per > IP addresses - as well as the ability for the node to rekey. > SPI can typically be used to proceed to clean key update and the SPI valu= e > may be used to indicate which key is being used. > This can typically be implemented by a SPI being encoded with the Securit= y > Association Database (SAD) entry on a subset of bytes (for example 3 > bytes), while the remaining byte is left to indicate the rekey index. > > The use of a smaller number of SPIs across communications comes with > privacy and security concerns. > Typically some specific values or subset of SPI values may reveal the > models or manufacturer of the node implementing ESP. > This may raise some privacy issues as an observer is likely to be able to > determine the constrained devices of the network. > In some cases, these nodes may host a very limited number of applications > - typically a single application - in which case the SPI would provide so= me > information related to the application of the user. > In addition, the device or application may be associated with some > vulnerabilities, in which case specific SPI values may be used by an > attacker to discover vulnerabilities. > > While the use of randomly generated SPI may reduce the leakage or privacy > or security related information by ESP itself, these information may also > be leaked otherwise and a privacy analysis should consider at least the > type of information as well the traffic pattern. > Typically, temperature sensors, wind sensors, used outdoors do not leak > privacy sensitive information and most of its traffic is expected to be > outbound traffic. > When used indoors, a sensor that reports every minute an encrypted status > of the door (closed or opened) leaks truly little privacy sensitive > information outside the local network. > > > > >> Section 4: >> - The third/fourth paragraph speaks to the potential use of a clock for >> the >> sequence counter, which if using an absolute clock with sufficiently fin= e >> granularity could maybe work. But stronger language to that granularity >> is >> required, the example lists one where periodicity =E2=80=9Cmay be=E2=80= =9D every 60sec, >> but >> there are many devices who will have millisecond (or finer?) >> granularity=E2=80=A6.so >> stronger caution and care descriptions are required. > > > > The third paragraph says that even if a node knows the other peers does > not implement antireplay, it must increase the SN. > > The 4th paragraphe details one way to increment SN based on time. On a > sender side, the only constraint is that the SN never repeats, so the > granularity seems to me that the clock must be that every packet is sent = at > a different time. If I interpret correctly the your comment, I think the > text below addresses the concern. > > """ > Using time for SN would guarantee a strictly > increasing function and avoid storing any additional values or > context related to the SN. When the use of a clock is considered, > one should take care that packets associated to a given SA are not > sent with the same time value. > """ > > Maybe the concern is regarding the synchronization between the sender and > the receiver. The current text mentions that if the sender uses a clock a= nd > the receiver considers an incremental counter value, an anti replay > mechanism is likely to reject the packets. > I think that we could add text to mention that an anti replay window > should take into account time derivation of the devices. I think that bot= h > recommendations should be moved to the receiver paragraph. > So the concern of the receiver implementing a counter base anti-replay > mechanism remains in this section but anti replay mechanisms related to S= N > have been moved to the receiving paragraph. > > I have also reworded some text in the sendin paragraph, but not changed > the main structure. Here is the current text: > > Usually, SN is generated by incrementing a counter for each packet sent. > A constraint device may avoid maintaining this context and use another > source that is known to always increase. > Typically, constraint nodes using 802.15.4 Time Slotted Channel Hopping > (TSCH), whose communication is heavily dependent on time, can take > advantage of their clock to generate the SN. > A lot of IoT devices are in a sleep state most of the time wake up and ar= e > only awake to perform a specific operation before going back to sleep. > > They do have separate hardware that allows them to wake up after a certai= n > timeout, and most likely also timers that start running when the device w= as > booted up, so they might have a concept of time with certain granularity. > This requires to store any information in a stable storage - such as flas= h > memory - that can be restored across sleeps. > Storing information associated with the SA such as SN requires some read > and writing operation on a stable storage after each packet is sent as > opposed to SPI or keys that are only written at the creation of the SA. > Such operations are likely to wear out the flash, and slow down the syste= m > greatly, as writing to flash is not as fast as reading. > Their internal clocks/timers might not be very accurate, but they should > be enough to know that each time they wake up their time is greater than > what it was last time they woke up. > Using time for SN would guarantee a strictly increasing function and avoi= d > storing any additional values or context related to the SN. > When the use of a clock is considered, one should take care that packets > associated to a given SA are not sent with the same time value. > Note however that standard receivers are generally configured with > incrementing counters and, if not appropriately configured, the use of a > significantly larger SN may result in the packet out of the receiver's > windows and that packet being discarded. > > > >> - The considerations for a >> receiver seems lengthy and am not sure of the point being stressed, othe= r >> than >> to RECOMMEND the use of anti-replay protection. I expected a descriptio= n >> for >> the need of a replay window and the window being set to discriminate to >> the >> worst case scenario (e.g. if on a wireless noisy medium where there is >> packet >> loss, then there may be a say 10ms loss/retry window). I am not >> understanding >> the example of the temperature sensor and the relevance to the SN. > > More >> concerning to me is the last sentence: =E2=80=9CA node MAY drop anti-rep= lay >> =E2=80=A6..instead >> implant its own internal mechanism=E2=80=9D? Is the intent to say if the= receiver >> has a >> different algorithm independent of the use of SN, then it MAY choose tha= t >> over >> the use of SN? > > > The intent of the paragraph is to indicate that anti replay is not > mandatory. > The paragraph has been slightly updated to clarify the sensor use case > where implementing anti replay comes with similar issues for a > constraint device as the use of a counter - that is storing a value in a > memory for any received packets. > There are cases where the anti replay mechanism might not be as necessary > as we may think. We expose some anti replay mechanisms that are based on > time and mention some considerations to set the window. > However, we do not provide explicit value as these are expected to be > dependent on the network or type of application. > I hope the text exposes in a clearer way the use case of the sensor as > well as the purpose of the paragraph. Here is the current text: > > For inbound traffic, it is RECOMMENDED that any receiver provides > anti-replay protection, and the size of the window depends on the ability > of the network to deliver packets out of order. > As a result, in an environment where out of order packets is not possible > the window size can be set to one. > However, while RECOMMENDED, there are no requirements to implement an > anti-replay protection mechanism implemented by IPsec. > Similarly to the SN the implementation of anti replay protection may > require the device to write the received SN for every packet, which may i= n > some cases come with the same drawbacks as those exposed for SN. > > As a result, some implementations MAY drop an non required anti replay > protection especially when the necessary resource involved overcomes the > benefit of the mechanism. > A typical example might consider an IoT device such as a temperature > sensor that is sending a temperature every 60 seconds, and that receives = an > acknowledgement from the receiver. > In such cases, the ability to spoof and replay an acknowledgment is of > limited interest and may not justify the implementation of an anti replay > mechanism. > > Receiving peers may also implement their own anti-replay mechanism. > Typically, when the sending peer is using SN based on time, anti-replay > may be implemented by discarding any packets that present a SN whose valu= e > is too much in the past. > Note that such mechanisms may consider clock drifting in various ways in > addition to acceptable delay induced by the network to avoid the anti > replay windows rejecting legitimate packets. > When a packet is received at a regular time interval, some variant of tim= e > based mechanisms may not even use the value of the SN, but instead only > consider the receiving time of the packet. > > > >> > >> - I might challenge due to potential collision attacks that at >> most, 2^32-1 packets may be sent before the SPI *must* rekey, so the SN >> and how >> it is used is part of the security context for the SPI/SA. I might also >> challenge that a recommendation for using a rekey mechanism is warranted >> because constrained devices tend to stay up for very, very, very long >> periods >> of time and even with an ESN there can be exhaustion :-) >> >> > --- > ISSUE 1 > --- > I am missing the concern. I understand the first concern is that the > current text seems to push the limit of packets being sent being determin= ed > by the SN as opposed to cryptographic properties. If my understanding is > correct, I have the current text seems clear that crypto properties are > given priorities. I suspect more guidance would be given. If that is the > case, I find it difficult as these guidances are really based on the > cryptographic algorithm and the key sizes. In any case, if I am > missing something, feel free to propose some text. > > """ > Note that the limit of messages being sent is primarily determined by the > security associated with the key rather than the SN. > The security of all data protected under a given key decreases slightly > with each message and a node MUST ensure the limit is not reached - even > though the SN would permit it. > """ > > I understand the second concern as that current text is read as rekey > mechanisms are recommended only when there is a risk the SN get exhausted= . > Our intention was to read the text as even if ESN raises the limit to an > acceptable limit, it is preferred to have a rekey mechanism. I propose th= e > following text to clarify the meaning: > > OLD: > In a constrained environment, it is likely that the implementation of a > rekey mechanism is preferred over the use of ESN. > > NEW: > Estimation of the maximum number of packets to be sent by a node is alway= s > challenging and as such should be considered cautiously as nodes could be > online for much more time than expected. > Even for constrained devices, it is RECOMMENDED to implement some rekey > mechanisms (see ). > > >> Section 5: >> - If a constrained device does use AES-CBC then padding may be needed, >> shouldn=E2=80=99t that be considered here? That is, it seems that paddin= g is >> dependent >> on the cipher negotiated, right? - =E2=80=9CTFC cannot be enable with mi= nimal ESP=E2=80=9D >> seems subjective, given that this is the guidelines perhaps it is a >> SHOULD NOT >> (or NOT RECOMMENDED)? >> >> > I interpret your concern as if the current document were not mandating th= e > padding. My understanding of the section is that we mostly mention how th= e > padding should be built and that the format should not be checked by the > minimal implementation. > I also believe that the case of AES-CBC has been addressed with the > following sentence. Feel free however to let me know if I mis-interpreted > your comment. > > """ > The purpose of padding is to respect the 32 bit alignment of ESP or block > size expected by an encryption transform - such as AES-CBC for example. > ESP MUST have at least one padding byte Pad Length that indicates the > padding length. > """ > > I think it makes sense to have it as a recommendation, and here is the ne= w > text: > > OLD: > As such TFC is not > expected to be supported by a minimal ESP implementation. > > NEW: > s such it is NOT RECOMMENDED that minimal ESP implementation supports TFC > """ > > > >> Section 6: >> - More concise language/guidance on minimal ESP is required, e.g. =E2=80= =9Cit is >> not >> expected to be part of minimal=E2=80=9D needs to be stronger. So, Next = Header is >> mandatory, so guidance is that the field is there=E2=80=A6..but is the >> recommendation >> for =E2=80=9Cminimal ESP=E2=80=9D be that it can ignore the field? >> >> > The Next Header is a mandatory field, so the minimal ESP needs to support > it, which support the ability to remove "no next header packet". I am > unsure what needs to be added to the text as it specifies: > > """ > the Next Header is a mandatory 8 bits field in the packet [...] > """ > and > """ > [...] a minimal ESP implementation MUST discard dummy packets. > """ > I understand that the etxt needed to be more concise. Here are two > sentences I changed. Let me know if there are other I am missing. > > > OLD: > Next header is intended to specify the data contained in the payload as > well as dummy packet, [...] > > NEW: > Next header specifies the data contained in the payload as well as dummy > packet > > OLD: > it is not expected to be part of a minimal implementation of ESP. > > NEW: > As a result, it SHOULD NOT be part of a minimal implementation of ESP > > > I am a bit reluctant saying that a minimal ESP SHOULD NOT send dummy > packet as RFC4303 mentions: > > """ > > A transmitter MUST be capable of > generating dummy packets marked with this value in the next protocol > > """ > > >> Section 7: >> - Do you mean authentication only w/no encryption? >> >> > considering the previous comments as well, here is the new text I propose= : > > OLD: > As detailed in we recommend using > authentication, the ICV field is expected to be present that is to say wi= th > a size different from zero. > This makes it a mandatory field which size is defined by the security > recommendations only. > > NEW: > As detailed in RFC8221 authentication or authenticated encryption are > RECOMMENDED and as such the ICV field MUST be present with a size differe= nt > from zero. > It length is defined by the security recommendations only. > > > Section 8: >> This section starts with eluding that guidelines for cipher selection >> criteria >> are provided, but as I read the list they are more considerations than >> they are >> guidelines? > > > Yes, I did not want to duplicate the cryptographic recommendations listed > in RFC8221 - which includes some IoT specific recommendations. I agree th= at > the section may be considered as guidelines but it seems ESP is a bit > decoupled from the cryptography used. > > > >> - Currently, the ciphers that provide confidentiality always >> include authentication, so not sure the motivation for the last sentence= ? > > > If the last sentence is > """ > Recommendations are provided for standard nodes as well as constrained > nodes. > """ > > The intention was to mention that the recommendations do not necessarily > apply to a constrained environment. I agree it does not appear to be > essential, so I removed it. > > > >> - >> Resilience to nonce reuse goes to the SN considerations as well (see my >> comments for Section 4). > > > ---- > ISSUE 2 > --- > I think I misunderstood your comment in both places so I leave it open. > > >> Another recommendation here is to also suggest that >> the provisioned key (and key should be clarified as =E2=80=9Cpre-shared = key=E2=80=9D) >> should >> also be updated with some regularity to address this issue (as in the >> rekey >> mechanism could lie in the management plane that provisions these keys). >> > > Though we do not mention "pre-shared" keys, I am wondering if the text in > the security consideration does not address your purpose: > > """ > It is RECOMMENDED to use ESP in conjunction of key management protocol= s > such as for example IKEv2 or minimal IKEv2 target=3D"RFC7815"/>. > Such mechanisms are responsible to negotiate fresh session keys as well a= s > prevent a session key being use beyond its lifetime. > > When such mechanisms cannot be implemented and the session key is, for > example, provisioned, the nodes MUST ensure that keys are not used beyond > their lifetime and that the appropriated use of the key remains across > reboots - e.g. conditions on counters and nonces remains valid. > > """ > > >> Currently RFC8452 is not cited as negotiated ciphers in RFC 8221, so >> considerations for 96bit nonce which doesn=E2=80=99t fit into the ESP he= ader, so >> while >> a general alternative not sure how you would apply it to ESP unless >> changes are >> made? > > > --- > ISSUE 3 > --- > This is correct that AES-GCM-SIV was not mentioned in RFC8221, and I > mentioned it as an example. Now, it seems more problematic to have an > example of a cipher suite that does not work for ESP. > I am balanced between indicating that its support is not defined with ESP > so the reader still has a reference to an example of such a cipher suite. > > I will raise this issue to the WG, but currently the text is as follows: > > """ > When the key is likely to be re-used across reboots, it is RECOMMENDED to > consider transforms that are nonce misuse > resistant such as AES-GCM-SIV for example. Note > however that AES-GCM-SIV has not yet been defined for ESP. > """ > > >> - What is the point driven in =E2=80=9Cinteroperability=E2=80=9D? Is it= that constrained >> devices may have limited interoperability given that they may not suppor= t >> all >> ciphers in RFC 8221? > > > It is more that what the other nodes supports needs to be considered in > the selection of the cipher suite. While RFC 8221 ensures smooth > transition, contrainted devices have less interoperability requirements. > > > >> - Similarly, for the power consumption and cipher suite >> complexity; is the point that ciphers are chosen based on the constraint= s >> (physical, computational and memory) of the device? >> >> > yes. > > >> Nits: >> General throughout the draft: =E2=80=9Cconstraint devices=E2=80=9D sho= uld be >> =E2=80=9Cconstrained >> devices=E2=80=9D. >> >> > thanks. I changed them all. > > >> Abstract: >> - Last sentence of first paragraph first clause is awkward =E2=80=9CCon= strains >> include >> among other limiting=E2=80=A6.=E2=80=9D >> Perhaps you mean =E2=80=9CSome constraints include limiting the=E2=80=A6= =E2=80=9D >> > > done. thanks. > > >> - Some qualification of =E2=80=9Cwhat is required from RFC 4303=E2=80= =9D is required=E2=80=A6. >> Perhaps you mean =E2=80=9Cthe minimally required set of functions and st= ates from >> RFC >> 4303 to achieve compliance and interoperability=E2=80=9D? My suggestion = may be to >> just >> remove this 2nd paragraph as its covered in the 3rd (though I think noti= ng >> interoperability should be there too). >> > > I agree. done. > > >> - I would think that there would be a strong issue if there are >> conflicts with >> RFC 4303?! So would suggest to remove that sentence or >> Only that the RFC 4303 remains the authoritative spec to detail full >> details of >> ESP. >> >> > done. thanks > > >> Section 2: >> - =E2=80=9Cconstraint devices=E2=80=9D should be =E2=80=9Cconstrained d= evices=E2=80=9D >> >> Section 8: >> - For =E2=80=9CSecurity=E2=80=9D, suggest=E2=80=A6=E2=80=9DThe chosen en= cryption algorithm MUST NOT be >> known to >> be vulnerable or weak=E2=80=9D >> >> > done. thanks. > > >> >> >> _______________________________________________ >> Lwip mailing list >> Lwip@ietf.org >> https://www.ietf.org/mailman/listinfo/lwip >> > > > -- > Daniel Migault > Ericsson > --=20 Daniel Migault Ericsson --00000000000012218705bef371cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Nancy,=C2=A0

Regarding ISSUE 3, I have the impression that the= concern that=C2=A0AES-GCM, Chacha20-Poly1= 305 or AES-CCM only send a 64 bit IV which suggest that only 64 bit IV can = be sent with ESP.=C2=A0
In fact the IV is not a field in ESP= but is defined for each suite, as a result, ESP would be able to support a= ny suite with larger or short IV. Then, the use of a 96 bit nonce is not un= common, actually AES-GCM and Chacha20-Poly1305 do use 96 bit nonce and AES-= CCM uses a 88 bit nonce. The nonce is formed based on a slat and the IV. Si= milar construction may be provided for AES-GCM-SIV if needed as far as I ca= n see.
=C2=A0 =C2=A0=C2=A0
AES-GCM-SIV is only defined as an algorithm, I als= o suggest=C2=A0to add other alternatives that have a similar=C2=A0goals. Th= e current text is as follows and I think it might close the ISSUE 3.=C2=A0<= /font>

When the key is likely to be re-used across r= eboots, it is RECOMMENDED to consider algorithms that are nonce misuse resi= stant such as, for example, AES-SIV [RFC5297], AES-GCM-SIV [RFC8452] or Deo= xys-II [deoxys].
Note however that currently none of them has yet been d= efined for ESP.=C2=A0

I suspect the ISSUE 1 an= d ISSUE 2 are related to IV collision. If so it seems to me related to the= =C2=A0 collision of IV. If so I think the current proposed text for SN addr= esses the concerns that an algorithm should not be used beyond its limits. = In addition the following text in the security consideration seems=C2=A0to = address that concern as well:
<= font face=3D"arial, sans-serif">
the nodes MUST ensure t= hat keys are not used beyond their lifetime and that the appropriate= use of the key remains across reboots - e.g. conditions on counters and no= nces remains valid. =C2=A0
=
I suspect that colli= sion is related to the collision of IV which is only a concern=C2=A0when th= e IV needs to be unpredictable.=C2=A0 I am tempted to think that algorithms= that the properties of the IV are really part of the algorithm properties = and that they cover / include into the lifetime of the keys. On the other h= and, most recommended algorithms AES-GCM, AES-CCM, Chacha-Poly1305 are usin= g IVs that just do not need to repeat,=C2=A0and so use counters where colli= sion is not a concern. Of course this does not concerne collision across=C2= =A0reboot, but I do not think these were the collisions that caused your co= ncern.=C2=A0 If I am correct, that probably also addresses ISSUEs 1 and ISS= UE 2.=C2=A0

I will publish the vers= ion with the current=C2=A0changes so reviews have the most recent editorial= changes and will update from that according to your response. Again thank = you for the in depth review and the many comments that already result in ma= ny clarifications - at least=C2=A0I think so.=C2=A0

Yours,=C2=A0
D= aniel

On Tue, Mar 30, 2021 at 10:45 PM Daniel Migault <mglt.ietf@gmail.com> wrote:
H= i Nancy,

Thank you very much for your review. Plea= se see inline my responses. I believe all concerns raised have been address= ed. I also believe the current text addresses some concerns also raised by = Paul W.=C2=A0

The current=C2=A0version can be foun= d here:

I t= hink there are however three remaining issues that might get further discus= sions. For all=C2=A0of these I provided a response, but I am unsure it real= ly addresses the three concerns below:

----
<= div>ISSUE 1
----
- I might challenge due to potential c= ollision attacks that at
most, 2^32-1 packets may be sent before the SPI *must* rekey, so the SN and= how
it is used is part of the security context for the SPI/SA.=C2=A0 I might al= so
challenge that a recommendation for using a rekey mechanism is warranted because constrained devices tend to stay up for very, very, very long perio= ds
of time and even with an ESN there can be exhaustion :-)

=
I am missing the concern. I understand the first concern is= that the current text seems to push the limit of packets being sent being = determined by the SN as opposed to cryptographic properties. If my understa= nding is correct, I have the current text seems clear that crypto propertie= s are given priorities. I suspect more guidance would be given. If that is = the case, I find it difficult as these guidances are really based on the cr= yptographic algorithm and the key sizes. In any case, if I am missing=C2=A0= something, feel free to propose some text.=C2=A0=C2=A0

=
"""
Note that the limit of messages being sen= t is primarily determined by the security associated with the key rather th= an the SN.
The security of all data protected under a given key decrease= s slightly with each message and a node MUST ensure the limit is not reache= d - even though the SN would permit it.
"""=C2= =A0

I understand the second concern as that curren= t text is read as rekey mechanisms are recommended only when there is a ris= k the SN=C2=A0get exhausted. Our intention was to read the text as even if = ESN raises the limit to an acceptable limit, it is preferred to have a reke= y mechanism. I propose the following text to clarify the meaning:

OLD:
In a constrained environment, it is likely t= hat the implementation of a rekey mechanism is preferred over the use of ES= N.

NEW:
Estimation of the maximum nu= mber of packets to be sent by a node is always challenging and as such shou= ld be considered cautiously as nodes could be online for much more time tha= n expected.
Even for constrained devices, it is RECOMMENDED to implement= some rekey mechanisms (see <xref target=3D"sec-security-considerat= ions"/>).=C2=A0=C2=A0
</mglt>
---
ISSUE 2
---
-
Resilience to nonce reuse goes to the SN considerations as well (see my
comments for Section 4).

---
ISSUE 3=
---
= Currently RFC8452 is not cited as negotiated ciphers in RFC 8221, so
considerations for 96bit nonce which doesn=E2=80=99t fit into the ESP heade= r, so while
a general alternative not sure how you would apply it to ESP unless changes= are
made?
<mglt>

This is corre= ct that AES-GCM-SIV was not mentioned in RFC8221, and I mentioned it as an = example. Now, it seems more problematic to have an example of a cipher suit= e that does not work for ESP.=C2=A0=C2=A0
I am balanced between i= ndicating that its support is not defined with ESP so the reader still has = a reference to an example of such a cipher suite.=C2=A0

I will raise this issue to the WG, but currently the text is as follo= ws:

"""
When the key is likel= y to be re-used across reboots, it is RECOMMENDED to consider transforms th= at are nonce misuse
resistant such as AES-GCM-SIV for example<xref target=3D"<= span style=3D"color:rgb(215,0,95);background-color:rgb(255,84,84)">RFC8452<= /span>"/>. Note however that AES-GCM-SIV has no= t yet been defined for ESP.=C2=A0
"""
</mglt>
=
<= br>
Yours,=C2=A0
Daniel=C2=A0



On = Fri, Mar 26, 2021 at 7:27 PM Nancy Cam-Winget via Datatracker <noreply@ietf.org> wro= te:
Reviewer: Na= ncy Cam-Winget
Review result: Ready with Issues

General Comments
The document flows relatively well; I expect that the editors will fix
editorial/grammatical issues and I=E2=80=99ve noted a couple below. I did h= ave some
questions to some of the descriptions where I expected guidance but read th= e
text as being more considerations so asked questions for clarification.

Technical comments:
Section 2:
=C2=A0- The first paragraph speaks to other drafts defining minimal
=C2=A0exchanges/operations and compression to serve IoT;
and then states =E2=80=9CThis document describes the minimal properties and= ESP
implementation needs to meet.=E2=80=9D Needs more clarification, is it so t= hat it can
interoperate with non-minimal ESP (e.g. RFC 4303 as defined) or to Interope= rate
given a set of constraints e.g. the minimal set to be defined in this docum= ent
including RFC 7815, et al? I think it is the former but the flow of the
paragraph makes it unclear=E2=80=A6.

<mglt>

The purpose of = the document is to provide guidance=C2=A0to build a=C2=A0minimal ESP implem= entation that remains interoperable with the RFC4303 ESP. In addition to th= e properties that needs to be met by a minimal ESP implementation, the docu= ment also provides some guidance on how the properties may be implemented w= hile also meeting some constraints=C2=A0of specific environments. Here is t= he text I propose:

OLD:
This document describes the minimal propertie= s and ESP implementation needs to meet.

=

NEW:
This do= cument describes the minimal properties an ESP implementation needs to meet= to remain interoperable with RFC4303 ESP.
In addition, this document a= lso provides a set of options to implement these properties under certain c= onstrained environments.
</mglt>=C2=A0

Section 3:
- Why is it RECOMMENDED to have a randomly generated SPI?=C2=A0 The next pa= ragraph
claims that it is not necessary, which in reading RFC 4303 is the case.=C2= =A0 So
this statement seems to contradict The following paragraph that relaxes thi= s
constraint.=C2=A0 But the rationale doesn=E2=80=99t seem to coincide; e.g. = =E2=80=9CA node
provisioned with keys by a third party =E2=80=A6.uses a transform that does= n=E2=80=99t not
needs random data=E2=80=A6=E2=80=9D Isn=E2=80=99t relevant to the SPI which= is intended to be an
Index=E2=80=A6.so better clarification of the security concerns are require= d.=C2=A0 Perhaps
on the relaxation, inclusion of consideration of non-reuse and uniqueness o= f
the SPI to reduce replay and maybe cross SA attacks should also be included= .

<mglt>
Thanks for these comments, tha= t is helpful to clarify this section. While SPI do not need to be random th= is is usually how SPI are generated. As a result, using non random values r= aised a lot of discussions while the use of random did not raise any discus= sions. I think that is the reason the two visions have been documented in a= n unbalanced way.=C2=A0
I agree that the text could be clearer an= d much more concise. I have restructured the full section exposing what 430= 3 mentions regarding the generation of the SPI, what and whay SPI=C2=A0are = generally generated randomly as well as why and how non random SPI may be g= enerated.=C2=A0 I have also added a section that groups consideration on SP= I generation. I hope this is clearer now.

NEW:
RFC4303 does not require the SPI to be randomly generated over 32 bi= ts.
However, this is the RECOMMENDED way to generate SPIs as it provides= some privacy benefits and avoids, for example, correlation between ESP com= munications. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0
To randomly generate a 32 bit SPI, the node generates a random 3= 2 bit value, checks does not fall in the 0-255 range. =C2=A0
If the SPI = has an acceptable value, it is used to index the inbound session, otherwise= the SPI is re-generated until an acceptable value is found.=C2=A0

<= /div>However, some constrained nodes may be less concerned by the privacy p= roperties associated to SPIs randomly generated. =C2=A0 =C2=A0 =C2=A0 =C2= =A0
Examples of such nodes might include sensors looking to reduce thei= r code complexity, in which case the use of a predictive function to genera= te the SPI might be preferred over the generation and handling of random va= lues.
An example of such predictable function may consider the combinat= ion of a fixed value and the memory address of the SAD structure.
= For every incoming packet, the node will be able to point the SAD structure= directly from the SPI value. This avoids having a separate and additional = binding between SPI and SAD entries that is involved for every incoming pac= ket.

<= div>
OLD:
=C2=A0<t> It is RECOMMENDED to index each inb= ound session with a SPI randomly generate over 32 bits.
Upon the gener= ation of a SPI the peer checks the SPI is not already used and does not fal= l in the 0-255 range.
If the SPI has an acceptable value, it is used to= index the inbound session, otherwise the SPI is re-generated until an acce= ptable value is found.
A random generation provides a stateless way to = generate the SPIs, while keeping the probability of collision between SPIs = relatively low. </t>

<t> However, for some constrained n= odes, generating and handling 32 bit random SPI may consume too much resour= ce, in which case SPI can be generated using predictable functions or end u= p in a using a subset of the possible values for SPI.
In fact, the SPI = does not necessarily need to be randomly generated.
A node provisioned = with keys by a third party - e.g. that does not generate them - and that us= es a transform that does not needs random data may not have such random gen= erators. =C2=A0
However, nonrandom SPI and restricting their possible v= alues MAY lead to privacy and security concerns.
As a result, this alte= rnative should be considered for devices that would be strongly impacted by= the generation of a random SPI and after understanding the privacy and sec= urity impact of generating nonrandom SPI.</t>
</mglt= >=C2=A0

- The last paragraph goes to the consideration that constrained devices may=
suffer from long lag times Between breach-patch availability to actual
deployment (or lack thereof).=C2=A0 But that rationale, imho, Is not the mo= tivation
for predictable SPIs; unless the consideration is more that if they don=E2= =80=99t
adhere to Appropriate key refreshes and SPI rotation that could lead to rep= lay
attacks. On the privacy front, Predictability of SPIs in particular SAs cou= ld
over time help an attacker gain more information about The actual devices a= nd
behavior.

<mglt>
If a device of type "A&qu= ot; implements ESP that takes very limited values of SPI, an observer that = monitors the traffic that observes such values will be able to define that = there is a high probability=C2=A0the device is of type "A". When = these devices have vulnerabilities, the observer this information may be us= ed by the observer to infer potential vulnerabilities the device is subject= to. In my mind the observer=C2=A0is an attacker, so I would be tempted to = consider this as a drawback.=C2=A0
From your text I have the impr= ession that the use of these non random values for SPI may be used by an ad= ministrator to monitor potential vulnerabilities in its network - which cou= ld be seen as a feature. This is how I am reading the first sentence of you= r comment, but I might be missing it.=C2=A0

In any= case, I agree that this is not the rationale for using non random SPIs. In= my view that is more a drawback. "In addition" was intended to r= aise an additional security concern which is that knowing the SPI or not ch= anging the SPI will ease an attacker to forge packets with a valid=C2=A0SPI= . I agree with you that this is also associated with any long term ESP sess= ions and can be removed.=C2=A0

As mentioned above, I have restructured and shortened the text and here is= the content of the=C2=A0"Considerations over SPI generation" sec= tion:

NEW:=C2=A0

SPI that are not randomly generated over 32 bits MAY lead to privacy and = security concerns. =C2=A0
As a result, the use of alternative designs re= quires careful security and privacy reviews. =C2=A0
This section provides so= me considerations upon the adoption of alternative designs.
=C2=A0

Note that SPI value is used only for inbound traffic, as su= ch the SPI negotiated with IKEv2 RFC7296 or RFC7815 by a peer, is the value= used by the remote peer when it=C2=A0sends traffic.
As SPI is only use= d for inbound traffic by the peer, this allows each peer to manage the set = of SPIs used for its inbound traffic.
Similarly, the privacy concerns a= ssociated with the generation of nonrandom SPI is also limited to the incom= ing traffic.

When alternate designs are considered, it is likely tha= t the number of possible SPIs will be limited.
This limit should both c= onsider the number of inbound SAs - possibly per IP addresses - as well as = the ability for the node to rekey.
SPI can typically be used to proceed= to clean key update and the SPI value may be used to indicate which key is= being used.
This can typically be implemented by a SPI being encoded w= ith the Security Association Database (SAD) entry on a subset of bytes (for= example 3 bytes), while the remaining byte is left to indicate the rekey i= ndex.

The use of a smaller number of SPIs across communications come= s with privacy and security concerns.
Typically some specific values or = subset of SPI values may reveal the models or manufacturer of the node impl= ementing ESP.
This may raise some privacy issues as an observer is like= ly to be able to determine the constrained devices of the network.
In s= ome cases, these nodes may host a very limited number of applications - typ= ically a single application - in which case the SPI would provide some info= rmation related to the application of the user.
In addition, the device = or application may be associated with some vulnerabilities, in which case s= pecific SPI values may be used by an attacker to discover vulnerabilities. = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0
While the use of ra= ndomly generated SPI may reduce the leakage or privacy or security related = information by ESP itself, these information may also be leaked otherwise a= nd a privacy analysis should consider at least the type of information as w= ell the traffic pattern.
Typically, temperature sensors, wind sensors, u= sed outdoors do not leak privacy sensitive information and most of its traf= fic is expected to be outbound traffic.
When used indoors, a sensor that= reports every minute an encrypted status of the door (closed or opened) le= aks truly little privacy sensitive information outside the local network.= =C2=A0
=C2=A0=C2=A0=C2=A0

</mglt>= =C2=A0
Section 4:
- The third/fourth paragraph speaks to the potential use of a clock for the=
sequence counter, which if using an absolute clock with sufficiently fine granularity could maybe work.=C2=A0 But stronger language to that granulari= ty is
required, the example lists one where periodicity =E2=80=9Cmay be=E2=80=9D = every 60sec, but
there are many devices who will have millisecond (or finer?) granularity=E2= =80=A6.so
stronger caution and care descriptions are required.

=
=C2=A0<mglt>
The third paragraph says that even = if a node knows the other peers does not implement antireplay, it must incr= ease=C2=A0the SN.=C2=A0

The 4th paragraphe details= one way to increment SN based on time. On a sender side, the only constrai= nt is that the SN never repeats, so the granularity seems to me that the cl= ock must be that every packet is sent at a different time. If I interpret c= orrectly the your comment, I think the text below addresses the concern.=C2= =A0

"""
=C2=A0Using time = for SN would guarantee a strictly
=C2=A0 =C2=A0increasing function and a= void storing any additional values or
=C2=A0 =C2=A0context related to th= e SN.=C2=A0 When the use of a clock is considered,
=C2=A0 =C2=A0one shou= ld take care that packets associated to a given SA are not
=C2=A0 =C2=A0= sent with the same time value.=C2=A0=C2=A0
"""=

Maybe the concern is regarding the synchronizatio= n between the sender and the receiver. The current text mentions that if th= e sender uses a clock and the receiver considers an incremental counter val= ue, an anti replay mechanism is likely to reject the packets.=C2=A0
I think that we could add text to mention that an anti replay window sho= uld take into account time derivation of the devices. I think that both rec= ommendations should be moved to the receiver paragraph.=C2=A0
So = the concern of the receiver implementing a counter base anti-replay mechani= sm remains in this section but anti replay mechanisms related to SN have be= en moved to the receiving paragraph.=C2=A0 =C2=A0=C2=A0

I have also reworded some text in the sendin paragraph, but not chang= ed the main structure. Here is the current text:

U= sually, SN is generated by incrementing a counter for each packet sent.
= A constraint device may avoid maintaining this context and use another sour= ce that is known to always increase.
Typically, constraint nodes using 8= 02.15.4 Time Slotted Channel Hopping (TSCH), whose communication is heavily= dependent on time, can take advantage of their clock to generate the SN.A lot of IoT devices are in a sleep state most of the time wake up and ar= e only awake to perform a specific operation before going back to sleep. = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
They do have sep= arate hardware that allows them to wake up after a certain timeout, and mos= t likely also timers that start running when the device was booted up, so t= hey might have a concept of time with certain granularity.
This requires= to store any information in a stable storage - such as flash memory - that= can be restored across sleeps.
Storing information associated with the = SA such as SN requires some read and writing operation on a stable storage = after each packet is sent as opposed to SPI or keys that are only written a= t the creation of the SA.
Such operations are likely to wear out the fla= sh, and slow down the system greatly, as writing to flash is not as fast as= reading.
Their internal clocks/timers might not be very accurate, but t= hey should be enough to know that each time they wake up their time is grea= ter than what it was last time they woke up.
Using time for SN would gua= rantee a strictly increasing function and avoid storing any additional valu= es or context related to the SN.
When the use of a clock is considered, = one should take care that packets associated to a given SA are not sent wit= h the same time value.
Note however that standard receivers are generall= y configured with incrementing counters and, if not appropriately configure= d, the use of a significantly larger SN may result in the packet out of the= receiver's windows and that packet being discarded.
=C2= =A0
</mglt>=C2=A0
More
concerning to me is the last sentence: =E2=80=9CA node MAY drop anti-replay= =E2=80=A6..instead
implant its own internal mechanism=E2=80=9D? Is the intent to say if the re= ceiver has a
different algorithm independent of the use of SN, then it MAY choose that o= ver
the use of SN?
<mglt>
The intent of = the paragraph is to indicate that anti replay is not mandatory.=C2=A0
=
The paragraph has been slightly updated to clarify the sensor use case= where implementing anti replay comes with similar issues for a constraint= =C2=A0device as the use of a counter - that is storing a value in a memory = for any received packets.=C2=A0
There are cases where the anti re= play mechanism might not be as necessary as we may think. We expose some an= ti replay mechanisms that are based on time and mention some considerations= to set the window.=C2=A0
However, we do not provide explicit val= ue as these are expected to be dependent on the network or type of applicat= ion.=C2=A0
I hope the text exposes in a clearer=C2=A0way the use = case of the sensor as well as the purpose of the=C2=A0paragraph. Here is th= e current text:

For inbound traffic, it is RECOMME= NDED that any receiver provides anti-replay protection, and the size of the= window depends on the ability of the network to deliver packets out of ord= er.
As a result, in an environment where out of order packets is not pos= sible the window size can be set to one.
However, while RECOMMENDED, the= re are no requirements to implement an anti-replay protection mechanism imp= lemented by IPsec.
Similarly to the SN the implementation of anti replay= protection may require the device to write the received SN for every packe= t, which may in some cases come with the same drawbacks as those exposed fo= r SN.

As a result, some implementations MAY drop an non required ant= i replay protection especially when the necessary resource involved overcom= es the benefit of the mechanism.
A typical example might consider an IoT= device such as a temperature sensor that is sending a temperature every 60= seconds, and that receives an acknowledgement from the receiver.
In suc= h cases, the ability to spoof and replay an acknowledgment is of limited in= terest and may not justify the implementation of an anti replay mechanism.<= br>
Receiving peers may also implement their own anti-replay mechanism.<= br>Typically, when the sending peer is using SN based on time, anti-replay = may be implemented by discarding any packets that present a SN whose value = is too much in the past.
Note that such mechanisms may consider clock dr= ifting in various ways in addition to acceptable delay induced by the netwo= rk to avoid the anti replay windows rejecting legitimate packets.
When a= packet is received at a regular time interval, some variant of time based = mechanisms may not even use the value of the SN, but instead only consider = the receiving time of the packet.

</mglt>= ;=C2=A0
=C2=A0
-= I might challenge due to potential collision attacks that at
most, 2^32-1 packets may be sent before the SPI *must* rekey, so the SN and= how
it is used is part of the security context for the SPI/SA.=C2=A0 I might al= so
challenge that a recommendation for using a rekey mechanism is warranted because constrained devices tend to stay up for very, very, very long perio= ds
of time and even with an ESN there can be exhaustion :-)

=C2=A0<mglt>
---
ISSUE 1
---
I am missing the concern. I understand the first conc= ern is that the current text seems to push the limit of packets being sent = being determined by the SN as opposed to cryptographic properties. If my un= derstanding is correct, I have the current text seems clear that crypto pro= perties are given priorities. I suspect more guidance would be given. If th= at is the case, I find it difficult as these guidances are really based on = the cryptographic algorithm and the key sizes. In any case, if I am missing= =C2=A0something, feel free to propose some text.=C2=A0=C2=A0

=
"""
Note that the limit of messages bei= ng sent is primarily determined by the security associated with the key rat= her than the SN.
The security of all data protected under a given key de= creases slightly with each message and a node MUST ensure the limit is not = reached - even though the SN would permit it.
""&qu= ot;=C2=A0

I understand the second concern as that = current text is read as rekey mechanisms are recommended only when there is= a risk the SN=C2=A0get exhausted. Our intention was to read the text as ev= en if ESN raises the limit to an acceptable limit, it is preferred to have = a rekey mechanism. I propose the following text to clarify the meaning:

OLD:
In a constrained environment, it is li= kely that the implementation of a rekey mechanism is preferred over the use= of ESN.

NEW:
Estimation of the maxi= mum number of packets to be sent by a node is always challenging and as suc= h should be considered cautiously as nodes could be online for much more ti= me than expected.
Even for constrained devices, it is RECOMMENDED to imp= lement some rekey mechanisms (see <xref target=3D"sec-security-cons= iderations"/>).=C2=A0=C2=A0
</mglt>
Section 5:
- If a constrained device does use AES-CBC then padding may be needed,
shouldn=E2=80=99t that be considered here? That is, it seems that padding i= s dependent
on the cipher negotiated, right? - =E2=80=9CTFC cannot be enable with minim= al ESP=E2=80=9D
seems subjective, given that this is the guidelines perhaps it is a SHOULD = NOT
(or NOT RECOMMENDED)?

<mglt>
I interpret your concern as if= the current document were not mandating the padding. My understanding of t= he section is that we mostly mention how the padding should be built and th= at the format should not be checked by the minimal implementation.=C2=A0 = =C2=A0
I also believe that the case of AES-CBC has been addressed= with the following sentence. Feel free however to let me know if I mis-int= erpreted your comment.=C2=A0

"""
The purpose of padding is to respect the 32 bit alignment of ESP or= block size expected by an encryption transform - such as AES-CBC for examp= le.
ESP MUST have at least one padding byte Pad Length that indicates th= e padding length.
"""=C2=A0

I think it makes sense to have it as a recommendation, and here is t= he new text:

OLD:
As such TFC is not
= =C2=A0 =C2=A0expected to be supported by a minimal ESP implementation.
<= /div>

NEW:
s such it is NOT RECOMMENDED that minim= al ESP implementation supports TFC
""&qu= ot;
</mglt>
=C2=A0
Section 6:
- More concise language/guidance on minimal ESP is required, e.g. =E2=80=9C= it is not
expected to be part of minimal=E2=80=9D needs to be stronger.=C2=A0 So, Nex= t Header is
mandatory, so guidance is that the field is there=E2=80=A6..but is the reco= mmendation
for =E2=80=9Cminimal ESP=E2=80=9D be that it can ignore the field?

<mglt>
The Next Header is a mandatory= field, so the minimal ESP needs to support it, which support the ability t= o remove "no next header packet". I am unsure what needs to be ad= ded to the text as it specifies:

"""= ;
the Next Header is a mandatory 8 bits field in the packet [...]=
"""
and=C2=A0
""= ;"
[...] a minimal ESP implementation MUST discard dummy pac= kets.
"""
I understand that the etxt= needed to be more concise. Here are two sentences I changed. Let me know= =C2=A0if there are other I am missing.=C2=A0


<= /div>
OLD:
Next header is intended to specify the data contai= ned in the payload as well as dummy packet, [...]=C2=A0

<= /div>
NEW:
Next header specifies the data contained in the pa= yload as well as dummy packet

OLD:
i= t is not expected to be part of a minimal implementation of ESP.=C2=A0
<= /div>

NEW:
As a result, it SHOULD NOT be part = of a minimal implementation of ESP


<= div>I am a bit reluctant saying that a minimal ESP SHOULD NOT send dummy pa= cket as RFC4303 mentions:

"""
= 
A transmitter MUST be capable of
   generating dummy packets marked with this value in the next protocol
"""=C2=A0
</mglt>=C2=A0
Section 7:
- Do you mean authentication only w/no encryption?

<mglt>
considering the previous comme= nts as well, here is the new text I propose:

OLD:<= /div>
As detailed in <xref target=3D"sec-encr"/> we rec= ommend using authentication, the ICV field is expected to be present that i= s to say with a size different from zero.
This makes it a mandatory fiel= d which size is defined by the security recommendations only.
=C2= =A0
NEW:
As detailed in RFC8221 authentication or a= uthenticated encryption are RECOMMENDED and as such the ICV field MUST be p= resent with a size different from zero.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0=C2=A0
It length is defined by the security recommen= dations only.=C2=A0
</mglt>=C2=A0

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> Section 8:
This section starts with eluding that guidelines for cipher selection crite= ria
are provided, but as I read the list they are more considerations than they= are
guidelines?
<mglt>
Yes, I did not want to= duplicate the cryptographic recommendations listed in RFC8221 - which incl= udes some IoT specific recommendations. I agree that the section may be con= sidered as guidelines but it seems ESP is a bit decoupled from the cryptogr= aphy used.=C2=A0 =C2=A0
</mglt>
=C2=A0
- Currently, the ciphers that = provide confidentiality always
include authentication, so not sure the motivation for the last sentence? <= /blockquote>
=C2=A0<mglt>
If the last sentence is=C2=A0=
"""
Recommendations are provided for standa= rd nodes as well as constrained nodes.=C2=A0
&q= uot;""

The intention was to mention that= the recommendations do not necessarily apply to a constrained environment.= I agree it does not appear to be essential, so I removed it.=C2=A0
=C2=A0
</mglt>
-
Resilience to nonce reuse goes to the SN considerations as well (see my
comments for Section 4).
<mglt>
----
ISSUE 2
---
I think I misunderstood your comment = in both places so I leave it open.=C2=A0
</mglt>=C2=A0
Another recommendation h= ere is to also suggest that
the provisioned key (and key should be clarified as =E2=80=9Cpre-shared key= =E2=80=9D) should
also be updated with some regularity to address this issue (as in the rekey=
mechanism could lie in the management plane that provisions these keys).
<mglt>
Though we do not mention "pr= e-shared" keys, I am wondering if the text in the security considerati= on does not address your purpose:

""&quo= t;
<t>It is RECOMMENDED to use ESP in conjunction of key ma= nagement protocols such as for example IKEv2 <xref target=3D"RFC729= 6"/> or minimal IKEv2 <xref target=3D"RFC7815"/>.Such mechanisms are responsible to negotiate fresh session keys as well a= s prevent a session key being use beyond its lifetime.

When such mec= hanisms cannot be implemented and the session key is, for example, provisio= ned, the nodes MUST ensure that keys are not used beyond their lifetime and= that the appropriated use of the key remains across reboots - e.g. conditi= ons on counters and nonces remains valid.
</t>
"= ;""
</mglt>=C2=A0
Currently RFC8452 is not cited as negotiated ciphers in RFC 8221, so
considerations for 96bit nonce which doesn=E2=80=99t fit into the ESP heade= r, so while
a general alternative not sure how you would apply it to ESP unless changes= are
made?
<mglt>
---
ISSUE 3
<= div>---
This is correct that AES-GCM-SIV was not mentioned in RFC= 8221, and I mentioned it as an example. Now, it seems more problematic to h= ave an example of a cipher suite that does not work for ESP.=C2=A0=C2=A0
I am balanced between indicating that its support is not defined wi= th ESP so the reader still has a reference to an example of such a cipher s= uite.=C2=A0

I will raise this issue to the WG, but= currently the text is as follows:

""&qu= ot;
When the key is likely to be re-used across reboots, it is RECOMM= ENDED to consider transforms that are nonce misuse
resistant suc= h as AES-GCM-SIV for example<xref = target=3D"RFC8452&q= uot;/>. Note = however that AES-GCM-SIV has not yet been defined for ESP.=C2=A0
"""= ;
</mglt>
- What is the point driven in =E2=80=9Cinteroperability=E2=80=9D?=C2= =A0 Is it that constrained
devices may have limited interoperability given that they may not support a= ll
ciphers in RFC 8221?
<mglt>
It is more th= at what the other nodes supports needs to be considered in the selection of= the cipher suite. While RFC 8221 ensures smooth transition, contrainted de= vices have less interoperability requirements.=C2=A0=C2=A0
</m= glt>
=C2=A0
- Similarly, for the power consumption and cipher suite
complexity; is the point that ciphers are chosen based on the constraints (physical, computational and memory) of the device?

<mglt>
yes.
</mglt>= =C2=A0
Nits:
General throughout the draft:=C2=A0 =C2=A0=E2=80=9Cconstraint devices=E2=80= =9D should be =E2=80=9Cconstrained
devices=E2=80=9D.

<mglt>
thanks. I changed them all.
</mglt>=C2=A0
Abstract:
=C2=A0- Last sentence of first paragraph first clause is awkward =E2=80=9CC= onstrains include
=C2=A0among other limiting=E2=80=A6.=E2=80=9D
Perhaps you mean =E2=80=9CSome constraints include limiting the=E2=80=A6=E2= =80=9D
<mglt>
done. thanks.
</mglt&= gt;=C2=A0
=C2=A0- So= me qualification of =E2=80=9Cwhat is required from RFC 4303=E2=80=9D is req= uired=E2=80=A6.
Perhaps you mean =E2=80=9Cthe minimally required set of functions and state= s from RFC
4303 to achieve compliance and interoperability=E2=80=9D? My suggestion may= be to just
remove this 2nd paragraph as its covered in the 3rd (though I think noting<= br> interoperability should be there too).
<mglt>
I agree. done.
</mglt>=C2=A0
=C2=A0- I would think that there would be a strong issue if there are confl= icts with
=C2=A0RFC 4303?! So would suggest to remove that sentence or
Only that the RFC 4303 remains the authoritative spec to detail full detail= s of
ESP.

<mglt>
done. thanks
</mg= lt>=C2=A0
Section 2:
=C2=A0- =E2=80=9Cconstraint devices=E2=80=9D should be =E2=80=9Cconstrained= devices=E2=80=9D

Section 8:
- For =E2=80=9CSecurity=E2=80=9D, suggest=E2=80=A6=E2=80=9DThe chosen encry= ption algorithm MUST NOT be known to
be vulnerable or weak=E2=80=9D

<mglt>
done. thanks.
</m= glt>=C2=A0


_______________________________________________
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip


--
Daniel Migault
Ericsson


--
Daniel Migault
Ericsson
--00000000000012218705bef371cf-- From nobody Thu Apr 1 23:08:19 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C592D3A341B for ; Thu, 1 Apr 2021 23:08:17 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JELmSu_sQU5 for ; Thu, 1 Apr 2021 23:08:13 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 5E8EC3A3418 for ; Thu, 1 Apr 2021 23:08:13 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id v15so6185828lfq.5 for ; Thu, 01 Apr 2021 23:08:13 -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=+evD0P0j5z8+rpzTvi0komM+ouPj18OniB/BfMQMoD0=; b=NDJHs18/8ijb4JLw0brMcy6LU2a1fxBr5Rm5+vWCjeRp1q1VdGN7C7QRQcxMRiloGx f2w1Cx11VShjcfMjyzwgdksfVh8i54d/Lwkxhy5BpLyIBggLxAlRi17zSXFEo8J6pCrz I75pGWsAhTfUEeNv1MqSakCpxXK57y15Ez5hpt08UGipNyTn+nI/QyDBtRrrbqNnUdRx 6giXBTB7QRoUTpN3HI8QU7Tpf1dUapfEOygDxqxaUenCGvf8G16aS/GLWjKqEEWE8anV PsoLxdTQ34IdDUlH+i9nk5JV1YRhKmgzwxqOrgHOKQJvLN6MmY4ywQ7SHXEZVyhV+KQb BH4Q== 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=+evD0P0j5z8+rpzTvi0komM+ouPj18OniB/BfMQMoD0=; b=UavSFY11FKRLCsiWT3EIU5Lxl3YvRNekIBq/3rbaW5s5KF07fiYXoO0IUDtUWePNjl 3W08veQkpi+Sn1HaAF1lNO32OFJdD11yh+HtzETC3q9jLEso5M37g3ZiQwviwGRaVvR9 KAIqjDhv0IqjXJ4ehTitlVlbOwLQFrmw35zpLek348LxkUn176tGDAtN8zGLbhHUYtFF JwVnlnqo8Kc+x/nal+7j2HHvDJpCvN9Da3lRmSO26XZjdS6N3nLgBd7r6JXlJCgHoC/w feRFdUSc0cWmyn/ae/oHzeFaCRWnKxfMWxJ4+Xoyc3LD3lFRjyw5HJ4ml9fC1Tw7Y2fj Wjxw== X-Gm-Message-State: AOAM530HTwNkKsFS5ZEcBgIM4bFlBUCMCsmPnfugHqZggYAek7kLzW/m jhuZ2TI1BeQ99FlBU81sUpw= X-Google-Smtp-Source: ABdhPJxpeAtasAqUMCd79kLvOEPqXdzIVIm+pa24wWtG+8EaOLI/lrKEPb0q6rfQgMzuJNI4vR5JYQ== X-Received: by 2002:ac2:518e:: with SMTP id u14mr7571862lfi.225.1617343691117; Thu, 01 Apr 2021 23:08:11 -0700 (PDT) Received: from buildpc ([93.188.44.203]) by smtp.gmail.com with ESMTPSA id m7sm754978lfg.285.2021.04.01.23.08.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Apr 2021 23:08:10 -0700 (PDT) From: "Valery Smyslov" To: "'Tero Kivinen'" , "'Bottorff, Paul'" Cc: "'IPsec'" , References: <20210331103220.GA21137@moon.secunet.de> <24678.19440.553333.890224@fireball.acr.fi> In-Reply-To: <24678.19440.553333.890224@fireball.acr.fi> Date: Fri, 2 Apr 2021 09:08:13 +0300 Message-ID: <036401d72786$91047b90$b30d72b0$@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: AQFvBFBeVc8YQwtquwQS75oQnz2WTQJRErFpANOS/JYCNRDTH6tGNXFQ Content-Language: ru Archived-At: Subject: Re: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2021 06:08:18 -0000 Hi Tero, > For the load balancing I think it is enough for just one of the ports > to be different, thus initiator could simply allocate n random source > port numbers, and initiate IKE from each of them to responder, and > then create SAs for each of them separately, thus allowing load > balancing using UDP encapsulation using existing hardware. RFC 7791 + MOBIKE can be used to clone IKE SA and move it to a different local IP+port. Regards, Valery. > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Apr 2 14:59:23 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF833A2550 for ; Fri, 2 Apr 2021 14:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hpe.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xoXZTTlKOiYv for ; Fri, 2 Apr 2021 14:59:16 -0700 (PDT) Received: from mx0b-002e3701.pphosted.com (mx0b-002e3701.pphosted.com [148.163.143.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 443553A254F for ; Fri, 2 Apr 2021 14:59:15 -0700 (PDT) Received: from pps.filterd (m0150245.ppops.net [127.0.0.1]) by mx0b-002e3701.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 132LwhEf008782; Fri, 2 Apr 2021 21:59:15 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hpe.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=pps0720; bh=kc8AB5kvMuCwjkrOW5Mn3XU71gJQB407TYI3Oazzjh0=; b=ctEfD96dR88KK/iItGDQ9LO/e5ofHs22p67qQf7pgRZtXzbb6XiyAA+ZOiMiG77FSuvT AP4e7PBttXrUtrOYJFHtQcLuCC6g7ZkyXu9u1D3gpd4L1+AhKwVzYhUwnTlDWQkC7kfJ N0OAhhYzSmldJItnSe0Oplic1GjpFUMZ3HbLTbo8egScZeLkZAXUCHlvRbnGVsqg+CeV Z1yVUvq4qT4VAaKheMD+eJ3LDjNeAx03R+aMQhTz4yqm64qW9GRMjEINmzSUVfTmVa1l jPxzFRPrrmlf9ZYch7KsAX2vSLhy8VbAL67gEzNULViJmlwYbaEipyHVSs1L/3TopNLG WQ== Received: from g2t2352.austin.hpe.com (g2t2352.austin.hpe.com [15.233.44.25]) by mx0b-002e3701.pphosted.com with ESMTP id 37pafm0enn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 02 Apr 2021 21:59:14 +0000 Received: from G9W8454.americas.hpqcorp.net (exchangepmrr1.us.hpecorp.net [16.216.161.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by g2t2352.austin.hpe.com (Postfix) with ESMTPS id E52C69B; Fri, 2 Apr 2021 21:59:13 +0000 (UTC) Received: from G2W6310.americas.hpqcorp.net (2002:10c5:4034::10c5:4034) by G9W8454.americas.hpqcorp.net (2002:10d8:a104::10d8:a104) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 2 Apr 2021 21:59:13 +0000 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (15.241.52.13) by G2W6310.americas.hpqcorp.net (16.197.64.52) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 2 Apr 2021 21:59:13 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=E2l0YLfuU3Nuri9GCanNyjHQPBdeSXW4yg/9RSPI+Cr+YEW58JMFgLk/P5OFRf0s/3MOmXNmYHxZH4UZDheMRjGk2j5LwN/btvvuMWBUG3fLldoFDA8z/2cP5e072ZWLGBFzX4kXFekltaN+rfKq3zJQqtF/eQW8/nNZF9iaY5xgcyx1s41H0fXZGvzr+M115n+EDXyqgA7DCmbWfpPj5y4r4GNVKG58V+s3DQhZytud0lapn+XmBfYCx00jHtgXgtGBNkTPa4nnivj+L0SYyJZy6PkFstE/7YrGMMgidh0JSeGl7ztKO2YM4r4gcdwuU/lAYo3f/sBQU+UorNTvPA== 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=zdmaf61NT3qXEs7I8Ghtueu48YQRxsiFUl5qTH/2O/0=; b=eYBEiCXahYaOMsNWg+pmX3niqxx4wcgVIA+Ez5+4hCxKQuMLFTVIQYL9af6Ux6dwLIjqLVBNGV0IaunlWMssEdSTNg1dJHPsXRuiicSGp1IETg1f6Q6NtlOv1lqbtmsRwx/mu71JrBH5xV+a9Hz/aNmGDLihbBNgJIi7kEOqJysMgBVZJUoouw/k/8BKgGlflBAFoLxjp90J57BBH/eRaiDhyKS+UN+fOsyRas5+J8f6egwBpgmGI7E8oBBBVsux4Zl2Frs7HDtHKdzF4k5ETdOrtiC+hSt1dAu1dfmzfGlsuvaenjaPOXc8whrd5wxjmbnQGJhQrgwvnHE/Lh+YcA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=hpe.com; dmarc=pass action=none header.from=hpe.com; dkim=pass header.d=hpe.com; arc=none Received: from CS1PR8401MB1192.NAMPRD84.PROD.OUTLOOK.COM (2a01:111:e400:7507::23) by CS1PR8401MB0853.NAMPRD84.PROD.OUTLOOK.COM (2a01:111:e400:750e::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.29; Fri, 2 Apr 2021 21:59:12 +0000 Received: from CS1PR8401MB1192.NAMPRD84.PROD.OUTLOOK.COM ([fe80::bd7d:6948:a6d3:c04]) by CS1PR8401MB1192.NAMPRD84.PROD.OUTLOOK.COM ([fe80::bd7d:6948:a6d3:c04%5]) with mapi id 15.20.3999.029; Fri, 2 Apr 2021 21:59:12 +0000 From: "Bottorff, Paul" To: Valery Smyslov , 'Tero Kivinen' CC: 'IPsec' , "antony.antony@secunet.com" Thread-Topic: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07 Thread-Index: AdciaiROLLoGnn3oQyW5+9ys0PMxKgJRErFpANOS/JYCNRDTH6tGNXFQq2XEr5A= Date: Fri, 2 Apr 2021 21:59:12 +0000 Message-ID: References: <20210331103220.GA21137@moon.secunet.de> <24678.19440.553333.890224@fireball.acr.fi> <036401d72786$91047b90$b30d72b0$@gmail.com> In-Reply-To: <036401d72786$91047b90$b30d72b0$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=hpe.com; x-originating-ip: [165.225.243.15] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 44aa9f96-417b-41ab-93bc-08d8f6228ccb x-ms-traffictypediagnostic: CS1PR8401MB0853: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Hlt37O4JcScXaaIibgHKJAkOrtwXnIEaSo3tm+rQtGefhB0NL3ezE8o7sO8pfcorWKRAl5NeRMO4m9QYHlgddtprjbYRWQVVYElgZGN9DJcPD1b9ir3DKNVx3IVCqGPKprSbtfDuklvz+F5EYzvg4jiPkM77md4GC0dKYESruXuzk1Y8HYamN/a1DVv68bSRxSmy9KYIukitNiel299OFFsgGkMGEUjC7/UgSfwMw+4MByv7jmLYG5KY8iiZ1yH+w5xBO0ZXirbktPyU9w+TgkMRtlwMrIfLYKPoxgrvu0BmlZ7uFoX2IVubMaUUgwz0QOzGARA7hYtRMtR0OYTFFNUuEVIACU3HnLD+iBtAjJ+SRewOezdtRaXI6DnMnoTfgp7PsYf6C2/Ty2R89RWLbgH6a0w1+dwTJisKUyMaOfx+qdDNoTarZdOGg9Fk8jMCjhGlPVd14fxp5pi20AamdHWn+qNQ+oMX4bl1rUHG2wt2IdqxNdtnqQMwKqIFT8ILO+nARm2W5T7p+2KbaIssBImHrUfFwWWvVAQiYuZ/n0p+KaUN+Llneq74greC3zecWq+aTM0CleyLVPEyRm16v9RidrExe4/eoGIrKs2XMMV2WGAxYEnvMSfkFFXxDgh73Ad5ETsCiZd3Nil9CulsFr8C7gGnYEbvai9Y/IUz/StdvPAB69CIKd/5SGNnUT9eeTEFWit9G+hVrJ4HEoxK0FCtR52wVoU6bOdSJBA9WN3FvpEheWqVVhU2koMjEOXx x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CS1PR8401MB1192.NAMPRD84.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(39860400002)(376002)(346002)(136003)(396003)(366004)(7696005)(52536014)(966005)(478600001)(64756008)(110136005)(66946007)(55236004)(54906003)(86362001)(6506007)(55016002)(316002)(66556008)(66476007)(8936002)(186003)(83380400001)(8676002)(71200400001)(26005)(53546011)(33656002)(76116006)(9686003)(2906002)(66446008)(4326008)(38100700001)(5660300002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?jsnjsYwTtWY2/vIUbxfeAUzUeT72bF9Er4YBVJfO5s1RgH7wEZzodDjYfpfL?= =?us-ascii?Q?pWJ0j30AvFIewVLf16rLvVEPoU+s/e9CyKsFi/wR7XactUN/vEX9CjIfffUx?= =?us-ascii?Q?iCFAcyDdWTlbrI/Ybr6lua7sTJuck4xmAHM3GcgcEl7yHLmrdEO1tuNpnbtG?= =?us-ascii?Q?uXf/Q+/AHkyI/Cj87EzhHKK19cDfFoBnM0WADeYJwaVPiPczYDKlYE886Po5?= =?us-ascii?Q?wlpG5Sfu+Uwb7TNie4WM0x7C0lityUt3/LdtWCXv/bP+4zmqSHwQR+G4zej7?= =?us-ascii?Q?CPWANxwNe5wv0n+m1PjPl+VLdZLgH5RYBmVgOcZ3AkU7dab6N067WunDWbW6?= =?us-ascii?Q?hvDw7qPtv8LAig+QK/jZp0fIZDZbuqb7lnQdHeBQtIN41pRqVLhceZflOaxm?= =?us-ascii?Q?s3LhSJnMGHOXN7j6SbjR8GMk7vH1Pjqe72PsMP5H81qpGfv7DHJUo8sBKL++?= =?us-ascii?Q?K0YOFeTDz0KjZZXVxrinzv3ofxKh5LcScmweYfMzqCUgdsTXGGiWq1FUauwh?= =?us-ascii?Q?9xoN8WEg/ImjP2Pis41L1sD4PpDzNeDsupkUTiCygr0bf1bVYz3E1yB7r07C?= =?us-ascii?Q?e5Xb05RpPNAy66jAVvpDBvZNOrgeVGLQXONfPJVGGFumF4zqjK43x5rrzuWy?= =?us-ascii?Q?hNG3QDPU2DnxmTToaetqDBpQoQF48Breh/VottNoQ6KdKvxKkO49Iih72yNJ?= =?us-ascii?Q?uBWa7BqTJUP5oZhbifuGPCx2qh3jLA2CnBcdtKMiATlC3P3jfFZyWlDnzvWd?= =?us-ascii?Q?h1VkUCFOqz45A+x7DfhvdTWpBHmY12tVe6N62skXXdQa2D4wy2r0nG7QL1MJ?= =?us-ascii?Q?oGZi6UU+FMyZxlcRO44nGi0N1MXE1+WTiYfNzJIsaJxGemv6r/sQKEsR1PUe?= =?us-ascii?Q?vrIMKYQOeC3kj3kFWqtWxjV5oZ9+HSrc9YM+UzwdjVpI9itckKasF+iRWm5H?= =?us-ascii?Q?i5eOJsxDAhbSffIVGkOe6tTo+Mk8eQfuvEHW74C+pNVoTR4eHf48ZLeOKIai?= =?us-ascii?Q?pD1RjMwvVU3IN/x530bbDvPCVIRkGwEw3iIapRgIPcGJnRvuI3aCXLY1WS1E?= =?us-ascii?Q?hppT5dyKqUGDHCoYhhVGQ0oQQtF83TsMu3h017WXQ7UjT/WljmWOEFF5nV9j?= =?us-ascii?Q?l7O1zcPEto+H8HfRlmRrEScBgsdVQOQ8D2SgH9w+f9BXIYYJHekqyhAtEiu4?= =?us-ascii?Q?lu/WnJ7JdxhfEs6Wi8rR88aSs7BfSEVfwLbEvOTta5JEj7CAcCfIYSxzwQpW?= =?us-ascii?Q?eMNogYQ5MpYL7kLgklfkm5e0A6JZK1TN8vq0OjZChwWXrXEqNfB4CIq+2lKL?= =?us-ascii?Q?NZi1PyJYPB+0KpmIa+fsWgKC?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CS1PR8401MB1192.NAMPRD84.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 44aa9f96-417b-41ab-93bc-08d8f6228ccb X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2021 21:59:12.2958 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 7a/95s2TcEPPfRyqBj1aapHhAUC+nQlUuZaTxVMJHFfDFaUGX+1LJquxjk3+pdFPL9KrpbEMc+MfiK0WBT4AhQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CS1PR8401MB0853 X-OriginatorOrg: hpe.com X-Proofpoint-GUID: A2aeV4D94yWXslc0W7_1Kfkq4kKz4s4s X-Proofpoint-ORIG-GUID: A2aeV4D94yWXslc0W7_1Kfkq4kKz4s4s Content-Transfer-Encoding: quoted-printable X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-HPE-SCL: -1 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-04-02_15:2021-04-01, 2021-04-02 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 clxscore=1011 suspectscore=0 bulkscore=0 mlxlogscore=999 phishscore=0 malwarescore=0 lowpriorityscore=0 priorityscore=1501 spamscore=0 adultscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2103310000 definitions=main-2104020144 Archived-At: Subject: Re: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2021 21:59:22 -0000 Hi Valery: Agreed that LB only needs control of the source port to provide entropy.=20 Our application is for traversal of highly meshed data centre fabrics. We e= ncapsulate and de-encapsulate at the server using smart NICs and so don't h= ave any impact on RSS or host software (nor improvement over their standard= operation). We perform the encapsulation/de-encapsulation after the ESP pa= cket is formed. Since encapsulation occurs after and de-encapsulation occur= s before the IPsec stack, IPsec does not see any of the new port assignment= s so we don't have any issues with the SADB or IKE. Cheers, Paul -----Original Message----- From: Valery Smyslov [mailto:smyslov.ietf@gmail.com]=20 Sent: Thursday, April 1, 2021 11:08 PM To: 'Tero Kivinen' ; Bottorff, Paul Cc: 'IPsec' ; antony.antony@secunet.com Subject: RE: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07 Hi Tero, > For the load balancing I think it is enough for just one of the ports=20 > to be different, thus initiator could simply allocate n random source=20 > port numbers, and initiate IKE from each of them to responder, and=20 > then create SAs for each of them separately, thus allowing load=20 > balancing using UDP encapsulation using existing hardware. RFC 7791 + MOBIKE can be used to clone IKE SA and move it to a different l= ocal IP+port. Regards, Valery. > -- > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > INVALID URI REMOVED > man_listinfo_ipsec&d=3DDwICAg&c=3DC5b8zRQO1miGmBeVZ2LFWg&r=3DCCwOcKkISkWx= d8Ymy11M8VW3U6Peq8aJ_DDlgVbQW5E&m=3DykseXYzNH5MG1guNwTPMGiGby4o46mBhv92vwoS= pb0U&s=3DnCqbPzmEc1xdTkL0jPmKmNgH252j3dURPVnH8bt4OtE&e=3D From nobody Tue Apr 13 08:31:45 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A66D3A1B56; Tue, 13 Apr 2021 08:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LLX4CKMpfIO; Tue, 13 Apr 2021 08:31:36 -0700 (PDT) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 E57B13A1B4F; Tue, 13 Apr 2021 08:31:35 -0700 (PDT) Received: by mail-qv1-xf2b.google.com with SMTP id i9so8057628qvo.3; Tue, 13 Apr 2021 08:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=kez8tpJK4cUHlzYgdErKXBtA+dFBpE/egwSWH5qyy5Y=; b=DSXPS0BE1F8u9u2wH60QPRxzBNMT3C1tRSn13Aop2Td7NiaulSaRsX9fQj1HTsMd18 +96TwN+lpMb6lT3CACH+GLlnjGCrapNUGyGDpHlmtJyxdnjoDZDUs0JRhIFRXRY7EczT SoBHXbegrFNnso+92hNX1A/xQ7lWcww2e3208PyyLK/Uc9L7HtFg+rhhd20j0SjZZePZ 1Own8BKirJImujThM3D626Ow/SbN4CjZQckg9rBZWXVBHHYrPZhn7ftBt2S2WfXpGhfD FthbH1xeiSInPAZyOLhyt/YzSbDWnseb4QYpXk4vfsRVo7R8pXHaoVDCaGBo4JlTgior X7YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=kez8tpJK4cUHlzYgdErKXBtA+dFBpE/egwSWH5qyy5Y=; b=V/Pc53RByJwmTMDclAUwuTY+x05YKWFL/DftXpszyrZ3ZP6gDrY5S9Nj7zZ6v35msO b5H26kQVM8ZidxP94B+dZvTcAsN55EcXtwtcROk9A50ETGzB8KQz5u+VHATQk77dIaqc rjHqWz/jitzE1CNRQ3/WHwz7KiN6Kyhnpi4I4q/4un3+/DytZ/YKvYd0ZNhgGwcjtNGE cAb+jdS0i+fCEeiTMMGWzXvdeSop5gOQtY0jzPJ73yniVDDJ1YUOIGuk3qZ/q9xO80GI TyF93rpO/39rIRzbocBfQW9i9ZswgbKNP2Npiav6Dr0RC85nK1Q7zYOQkzsAJmbMeRom gigQ== X-Gm-Message-State: AOAM530yetwH/KcIW51SzjuqxR2i3xEq1YGqArxoMol8lER8irXXIDPI /PUUqF8A/pts9ZX7q9n2dFD5GEihQxqjS6HqQrdZEGnsYrA= X-Google-Smtp-Source: ABdhPJyhxBRQAjZ0vsLDR7T+8Kf0myk1brlogRnodJjfV0YXgMr2kHGZD7qA6HHxa0iX6xAt10pAuzGVk0LLHq8CXkY= X-Received: by 2002:ad4:408c:: with SMTP id l12mr15898081qvp.58.1618327894023; Tue, 13 Apr 2021 08:31:34 -0700 (PDT) MIME-Version: 1.0 References: <161832773550.14256.16807389807980830057@ietfa.amsl.com> In-Reply-To: <161832773550.14256.16807389807980830057@ietfa.amsl.com> From: Daniel Migault Date: Tue, 13 Apr 2021 11:31:23 -0400 Message-ID: To: lwip@ietf.org, IPsecME WG Content-Type: multipart/alternative; boundary="00000000000040e18c05bfdc538b" Archived-At: Subject: [IPsec] Fwd: [Lwip] I-D Action: draft-ietf-lwig-minimal-esp-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2021 15:31:41 -0000 --00000000000040e18c05bfdc538b Content-Type: text/plain; charset="UTF-8" Hi, Please find the current version that addresses all concerns currently received. Yours, Daniel ---------- Forwarded message --------- From: Date: Tue, Apr 13, 2021 at 11:29 AM Subject: [Lwip] I-D Action: draft-ietf-lwig-minimal-esp-05.txt To: Cc: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Light-Weight Implementation Guidance WG of the IETF. Title : Minimal ESP Authors : Daniel Migault Tobias Guggemos Filename : draft-ietf-lwig-minimal-esp-05.txt Pages : 15 Date : 2021-04-13 Abstract: This document describes a minimal implementation of the IP Encapsulation Security Payload (ESP) defined in RFC 4303. Its purpose is to enable implementation of ESP with a minimal set of options to remain compatible with ESP as described in RFC 4303. A minimal version of ESP is not intended to become a replacement of the RFC 4303 ESP. Instead, a minimal implementation is expected to be optimized for constrained environment while remaining interoperable with implementations of RFC 4303 ESP. Some constrains include limiting the number of flash writes, handling frequent wakeup / sleep states, limiting wakeup time, or reducing the use of random generation. This document does not update or modify RFC 4303, but provides a compact description of how to implement the minimal version of the protocol. RFC 4303 remains the authoritative description. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lwig-minimal-esp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lwig-minimal-esp-05 https://datatracker.ietf.org/doc/html/draft-ietf-lwig-minimal-esp-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-minimal-esp-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip -- Daniel Migault Ericsson --00000000000040e18c05bfdc538b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Please find the current versi= on that addresses all concerns currently received.=C2=A0

Yours,=C2=A0
Daniel=C2=A0

---------- Forwarded message ------= ---
From: <internet-drafts@ietf.org>
Date: Tue, Apr 13, 2021 at = 11:29 AM
Subject: [Lwip] I-D Action: draft-ietf-lwig-minimal-esp-05.txt<= br>To: <i-d-announce@ietf.org<= /a>>
Cc: <lwip@ietf.org><= br>



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Light-Weight Implementation Guidance WG of= the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Minimal ESP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Dani= el Migault
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Tobias Guggemos
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-lwig-minimal-esp-05.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 15
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2021-04-13

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

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


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-= ietf-lwig-minimal-esp/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lw= ig-minimal-esp-05
https://datatracker.ietf.org/doc= /html/draft-ietf-lwig-minimal-esp-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-lwig-minimal-esp-05


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip


--
Dani= el Migault
Ericsson
--00000000000040e18c05bfdc538b-- From nobody Wed Apr 21 01:11:31 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD87C3A1A8D for ; Wed, 21 Apr 2021 01:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 wyAFPRbUgxde for ; Wed, 21 Apr 2021 01:11:26 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E1983A1A8C for ; Wed, 21 Apr 2021 01:11:25 -0700 (PDT) Received: from fraeml702-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4FQCfl1MzGz74cr1 for ; Wed, 21 Apr 2021 16:01:03 +0800 (CST) Received: from nkgeml704-chm.china.huawei.com (10.98.57.158) by fraeml702-chm.china.huawei.com (10.206.15.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Wed, 21 Apr 2021 10:11:15 +0200 Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml704-chm.china.huawei.com (10.98.57.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Wed, 21 Apr 2021 16:11:14 +0800 Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.2176.012; Wed, 21 Apr 2021 16:11:14 +0800 From: "Panwei (William)" To: "ipsec@ietf.org" Thread-Topic: I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-04.txt Thread-Index: Adc2hQtbvPounrwPRTGrF0dTz3t3LA== Date: Wed, 21 Apr 2021 08:11:14 +0000 Message-ID: <32fea92125a040a3831695fa7f1510df@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.125.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [IPsec] FW: I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2021 08:11:31 -0000 Hi Chairs, folks, I've updated a new version of draft-kampati-ipsecme-ikev2-sa-ts-payloads-op= t. It's not a big update. I've received many good comments online/offline b= efore. I tried to address some of them, and there are still several comment= s under consideration. This draft tries to optimize the unnecessary payloads at the time of rekeyi= ng IKE SAs and Child SAs. If there is no changes of configuration on the pe= ers, they usually reuse the same crypto suites when rekeying the IKE SAs an= d Child SAs, so the SA and TS payloads will remain the same as the ones of = last rekeying. Therefore, the SA and TS payloads can be omitted at such con= dition. This optimization can save the bandwidth and power consumption. This draft was presented at IETF105 and IETF106, and received many good com= ments and supports. Paul also presented this topic at IETF110 (many thanks = to Paul) and mentioned that he wanted to implement it. After IETF110, Meili= ng Chen from China Mobile contacted to me privately, she believes this draf= t is valuable and can be used by them, thanks to her support and help of ed= iting the draft. To chairs: I feel many people are interested in this work and I wonder whet= her I can ask for an adoption call for this draft? To folks: any comments or feedbacks are very welcome. Regards & Thanks! Wei Pan > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf > Of internet-drafts@ietf.org > Sent: Wednesday, April 21, 2021 2:34 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-04.tx= t >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : IKEv2 Optional SA&TS Payloads in Child > Exchange > Authors : Sandeep Kampati > Wei Pan > Meduri S S Bharath > Meiling Chen > Filename : > draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-04.txt > Pages : 13 > Date : 2021-04-20 >=20 > Abstract: > This document describes a method for reducing the size of the > Internet Key Exchange version 2 (IKEv2) exchanges at time of rekeying > IKE SAs and Child SAs by removing or making optional of SA & TS > payloads. Reducing size of IKEv2 exchanges is desirable for low > power consumption battery powered devices. It also helps to avoid IP > fragmentation of IKEv2 messages. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-kampati-ipsecme-ikev2-sa-ts-payloa > ds-opt/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-kampati-ipsecme-ikev2-sa-ts-payloads-op= t > -04 > https://datatracker.ietf.org/doc/html/draft-kampati-ipsecme-ikev2-sa-ts-p > ayloads-opt-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-kampati-ipsecme-ikev2-sa-ts-pay= lo > ads-opt-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Sun Apr 25 02:33:02 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1FB93A124F for ; Sun, 25 Apr 2021 02:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNO1RP4egA67 for ; Sun, 25 Apr 2021 02:32:52 -0700 (PDT) Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with ESMTP id DC9053A1244 for ; Sun, 25 Apr 2021 02:32:49 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.3]) by rmmx-syy-dmz-app10-12010 (RichMail) with SMTP id 2eea6085372f3be-ddd7f; Sun, 25 Apr 2021 17:32:31 +0800 (CST) X-RM-TRANSID: 2eea6085372f3be-ddd7f X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from cmcc-PC (unknown[10.2.50.214]) by rmsmtp-syy-appsvr02-12002 (RichMail) with SMTP id 2ee26085372db87-f57a3; Sun, 25 Apr 2021 17:32:31 +0800 (CST) X-RM-TRANSID: 2ee26085372db87-f57a3 Date: Sun, 25 Apr 2021 17:32:44 +0800 From: "Meiling Chen" To: "Panwei (William)" , "ipsec@ietf.org" References: <32fea92125a040a3831695fa7f1510df@huawei.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.9.115[cn] Mime-Version: 1.0 Message-ID: <2021042517324396873910@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart563380421603_=----" Archived-At: Subject: Re: [IPsec] FW: I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Apr 2021 09:33:02 -0000 This is a multi-part message in MIME format. ------=_001_NextPart563380421603_=---- Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SGkgYWxsLA0KSSB0aGluayB0aGUgb3B0aW1pemF0aW9uIG9mIElQc2VjIHJla2V5IGlzIHZlcnkg aGVscGZ1bCwgSVBzZWMgaXMgdXNlZCB3aGVuIGFjY2Vzc2luZyB0aGUgY29yZSBuZXR3b3JrIHVz aW5nIG5vbi0zR1BQIG1ldGhvZCBhbmQgYWxzbyB1c2VkIHRvIHN1cHBvcnQgSVBzZWMgYmFzZWQg VlBOLA0Kd2hlbiB0aGVyZSBhcmUgbm8gY2hhbmdlcyBvZiBjb25maWd1cmF0aW9uIG9yIGNpcGhl ciBzdWl0ZXMsIHRoaXMgb3B0aW1pemF0aW9uIGlzIHdlbGwgd29ydGggZm9yIGJhbmR3aWR0aCBz YXZpbmcuIA0KDQoNCk1laWxpbmcuDQogDQpGcm9tOiBQYW53ZWkgKFdpbGxpYW0pDQpEYXRlOiAy MDIxLTA0LTIxIDE2OjExDQpUbzogaXBzZWNAaWV0Zi5vcmcNClN1YmplY3Q6IFtJUHNlY10gRlc6 IEktRCBBY3Rpb246IGRyYWZ0LWthbXBhdGktaXBzZWNtZS1pa2V2Mi1zYS10cy1wYXlsb2Fkcy1v cHQtMDQudHh0DQpIaSBDaGFpcnMsIGZvbGtzLA0KIA0KSSd2ZSB1cGRhdGVkIGEgbmV3IHZlcnNp b24gb2YgZHJhZnQta2FtcGF0aS1pcHNlY21lLWlrZXYyLXNhLXRzLXBheWxvYWRzLW9wdC4gSXQn cyBub3QgYSBiaWcgdXBkYXRlLiBJJ3ZlIHJlY2VpdmVkIG1hbnkgZ29vZCBjb21tZW50cyBvbmxp bmUvb2ZmbGluZSBiZWZvcmUuIEkgdHJpZWQgdG8gYWRkcmVzcyBzb21lIG9mIHRoZW0sIGFuZCB0 aGVyZSBhcmUgc3RpbGwgc2V2ZXJhbCBjb21tZW50cyB1bmRlciBjb25zaWRlcmF0aW9uLg0KIA0K VGhpcyBkcmFmdCB0cmllcyB0byBvcHRpbWl6ZSB0aGUgdW5uZWNlc3NhcnkgcGF5bG9hZHMgYXQg dGhlIHRpbWUgb2YgcmVrZXlpbmcgSUtFIFNBcyBhbmQgQ2hpbGQgU0FzLiBJZiB0aGVyZSBpcyBu byBjaGFuZ2VzIG9mIGNvbmZpZ3VyYXRpb24gb24gdGhlIHBlZXJzLCB0aGV5IHVzdWFsbHkgcmV1 c2UgdGhlIHNhbWUgY3J5cHRvIHN1aXRlcyB3aGVuIHJla2V5aW5nIHRoZSBJS0UgU0FzIGFuZCBD aGlsZCBTQXMsIHNvIHRoZSBTQSBhbmQgVFMgcGF5bG9hZHMgd2lsbCByZW1haW4gdGhlIHNhbWUg YXMgdGhlIG9uZXMgb2YgbGFzdCByZWtleWluZy4gVGhlcmVmb3JlLCB0aGUgU0EgYW5kIFRTIHBh eWxvYWRzIGNhbiBiZSBvbWl0dGVkIGF0IHN1Y2ggY29uZGl0aW9uLiBUaGlzIG9wdGltaXphdGlv biBjYW4gc2F2ZSB0aGUgYmFuZHdpZHRoIGFuZCBwb3dlciBjb25zdW1wdGlvbi4NCiANClRoaXMg ZHJhZnQgd2FzIHByZXNlbnRlZCBhdCBJRVRGMTA1IGFuZCBJRVRGMTA2LCBhbmQgcmVjZWl2ZWQg bWFueSBnb29kIGNvbW1lbnRzIGFuZCBzdXBwb3J0cy4gUGF1bCBhbHNvIHByZXNlbnRlZCB0aGlz IHRvcGljIGF0IElFVEYxMTAgKG1hbnkgdGhhbmtzIHRvIFBhdWwpIGFuZCBtZW50aW9uZWQgdGhh dCBoZSB3YW50ZWQgdG8gaW1wbGVtZW50IGl0LiBBZnRlciBJRVRGMTEwLCBNZWlsaW5nIENoZW4g ZnJvbSBDaGluYSBNb2JpbGUgY29udGFjdGVkIHRvIG1lIHByaXZhdGVseSwgc2hlIGJlbGlldmVz IHRoaXMgZHJhZnQgaXMgdmFsdWFibGUgYW5kIGNhbiBiZSB1c2VkIGJ5IHRoZW0sIHRoYW5rcyB0 byBoZXIgc3VwcG9ydCBhbmQgaGVscCBvZiBlZGl0aW5nIHRoZSBkcmFmdC4NCiANClRvIGNoYWly czogSSBmZWVsIG1hbnkgcGVvcGxlIGFyZSBpbnRlcmVzdGVkIGluIHRoaXMgd29yayBhbmQgSSB3 b25kZXIgd2hldGhlciBJIGNhbiBhc2sgZm9yIGFuIGFkb3B0aW9uIGNhbGwgZm9yIHRoaXMgZHJh ZnQ/DQpUbyBmb2xrczogYW55IGNvbW1lbnRzIG9yIGZlZWRiYWNrcyBhcmUgdmVyeSB3ZWxjb21l Lg0KIA0KUmVnYXJkcyAmIFRoYW5rcyENCldlaSBQYW4NCiANCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogSS1ELUFubm91bmNlIFttYWlsdG86aS1kLWFubm91bmNlLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj4g U2VudDogV2VkbmVzZGF5LCBBcHJpbCAyMSwgMjAyMSAyOjM0IFBNDQo+IFRvOiBpLWQtYW5ub3Vu Y2VAaWV0Zi5vcmcNCj4gU3ViamVjdDogSS1EIEFjdGlvbjogZHJhZnQta2FtcGF0aS1pcHNlY21l LWlrZXYyLXNhLXRzLXBheWxvYWRzLW9wdC0wNC50eHQNCj4gDQo+IA0KPiBBIE5ldyBJbnRlcm5l dC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj4g ZGlyZWN0b3JpZXMuDQo+IA0KPiANCj4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBJS0V2MiBP cHRpb25hbCBTQSZUUyBQYXlsb2FkcyBpbiBDaGlsZA0KPiBFeGNoYW5nZQ0KPiAgICAgICAgIEF1 dGhvcnMgICAgICAgICA6IFNhbmRlZXAgS2FtcGF0aQ0KPiAgICAgICAgICAgICAgICAgICAgICAg ICAgIFdlaSBQYW4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICBNZWR1cmkgUyBTIEJoYXJh dGgNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICBNZWlsaW5nIENoZW4NCj4gRmlsZW5hbWUg ICAgICAgIDoNCj4gZHJhZnQta2FtcGF0aS1pcHNlY21lLWlrZXYyLXNhLXRzLXBheWxvYWRzLW9w dC0wNC50eHQNCj4gUGFnZXMgICAgICAgICAgIDogMTMNCj4gRGF0ZSAgICAgICAgICAgIDogMjAy MS0wNC0yMA0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEg bWV0aG9kIGZvciByZWR1Y2luZyB0aGUgc2l6ZSBvZiB0aGUNCj4gICAgSW50ZXJuZXQgS2V5IEV4 Y2hhbmdlIHZlcnNpb24gMiAoSUtFdjIpIGV4Y2hhbmdlcyBhdCB0aW1lIG9mIHJla2V5aW5nDQo+ ICAgIElLRSBTQXMgYW5kIENoaWxkIFNBcyBieSByZW1vdmluZyBvciBtYWtpbmcgb3B0aW9uYWwg b2YgU0EgJiBUUw0KPiAgICBwYXlsb2Fkcy4gIFJlZHVjaW5nIHNpemUgb2YgSUtFdjIgZXhjaGFu Z2VzIGlzIGRlc2lyYWJsZSBmb3IgbG93DQo+ICAgIHBvd2VyIGNvbnN1bXB0aW9uIGJhdHRlcnkg cG93ZXJlZCBkZXZpY2VzLiAgSXQgYWxzbyBoZWxwcyB0byBhdm9pZCBJUA0KPiAgICBmcmFnbWVu dGF0aW9uIG9mIElLRXYyIG1lc3NhZ2VzLg0KPiANCj4gDQo+IFRoZSBJRVRGIGRhdGF0cmFja2Vy IHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPiBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1rYW1wYXRpLWlwc2VjbWUtaWtldjItc2EtdHMtcGF5bG9hDQo+IGRz LW9wdC8NCj4gDQo+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBh dDoNCj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWthbXBhdGktaXBzZWNtZS1p a2V2Mi1zYS10cy1wYXlsb2Fkcy1vcHQNCj4gLTA0DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2h0bWwvZHJhZnQta2FtcGF0aS1pcHNlY21lLWlrZXYyLXNhLXRzLXANCj4gYXls b2Fkcy1vcHQtMDQNCj4gDQo+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2 YWlsYWJsZSBhdDoNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWth bXBhdGktaXBzZWNtZS1pa2V2Mi1zYS10cy1wYXlsbw0KPiBhZHMtb3B0LTA0DQo+IA0KPiANCj4g UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUgb2YNCj4gc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlm ZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gSW50ZXJuZXQtRHJhZnRz IGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IEktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCj4g SS1ELUFubm91bmNlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaS1kLWFubm91bmNlDQo+IEludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiBodHRwOi8v d3d3LmlldGYub3JnL3NoYWRvdy5odG1sIG9yDQo+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFz aGFkb3ctc2l0ZXMudHh0DQogDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KSVBzZWMgbWFpbGluZyBsaXN0DQpJUHNlY0BpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYw0KIA0K ------=_001_NextPart563380421603_=---- Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0A
Hi all,
I think the optimization of IPs= ec rekey is very helpful, IPsec is used when accessing the core network us= ing non-3GPP method and also used to support IPsec based VPN,
wh= en there are no changes of configuration or cipher suites, this optimizati= on is well worth for bandwidth saving. 


=
Meiling.
 
=
Date: 2021-04-21 = 16:11
Subject: [IPsec] FW: I-D Action: draft-ka= mpati-ipsecme-ikev2-sa-ts-payloads-opt-04.txt
H= i Chairs, folks,
=0A
 
=0A
I've updated a new versi= on of draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt. It's not a big updat= e. I've received many good comments online/offline before. I tried to addr= ess some of them, and there are still several comments under consideration= .
=0A
 
=0A
This draft tries to optimize the unnece= ssary payloads at the time of rekeying IKE SAs and Child SAs. If there is = no changes of configuration on the peers, they usually reuse the same cryp= to suites when rekeying the IKE SAs and Child SAs, so the SA and TS payloa= ds will remain the same as the ones of last rekeying. Therefore, the SA an= d TS payloads can be omitted at such condition. This optimization can save= the bandwidth and power consumption.
=0A
 
=0A
Thi= s draft was presented at IETF105 and IETF106, and received many good comme= nts and supports. Paul also presented this topic at IETF110 (many thanks t= o Paul) and mentioned that he wanted to implement it. After IETF110, Meili= ng Chen from China Mobile contacted to me privately, she believes this dra= ft is valuable and can be used by them, thanks to her support and help of = editing the draft.
=0A
 
=0A
To chairs: I feel many= people are interested in this work and I wonder whether I can ask for an = adoption call for this draft?
=0A
To folks: any comments or feedb= acks are very welcome.
=0A
 
=0A
Regards & Than= ks!
=0A
Wei Pan
=0A
 
=0A
> -----Origin= al Message-----
=0A
> From: I-D-Announce [mailto:i-d-announce-= bounces@ietf.org] On Behalf
=0A
> Of internet-drafts@ietf.org<= /div>=0A
> Sent: Wednesday, April 21, 2021 2:34 PM
=0A
>= ; To: i-d-announce@ietf.org
=0A
> Subject: I-D Action: draft-k= ampati-ipsecme-ikev2-sa-ts-payloads-opt-04.txt
=0A
>
=0A=
>
=0A
> A New Internet-Draft is available from the on= -line Internet-Drafts
=0A
> directories.
=0A
> =0A
>
=0A
>      &nbs= p;  Title          = : IKEv2 Optional SA&TS Payloads in Child
=0A
> Exchange=0A
>         Authors&n= bsp;        : Sandeep Kampati
=0A<= div>>           =             &n= bsp;   Wei Pan
=0A
>     &n= bsp;           &nbs= p;         Meduri S S Bharath=0A
>          &= nbsp;           &nb= sp;    Meiling Chen
=0A
> Filename  =       :
=0A
> draft-kampati-ipsecme-i= kev2-sa-ts-payloads-opt-04.txt
=0A
> Pages   &= nbsp;       : 13
=0A
> Date&nbs= p;           : 2021-04-2= 0
=0A
>
=0A
> Abstract:
=0A
> &n= bsp;  This document describes a method for reducing the size of the=0A
>    Internet Key Exchange version 2 (IKEv2)= exchanges at time of rekeying
=0A
>    IKE SAs= and Child SAs by removing or making optional of SA & TS
=0A
= >    payloads.  Reducing size of IKEv2 exchanges is= desirable for low
=0A
>    power consumption b= attery powered devices.  It also helps to avoid IP
=0A
>&= nbsp;   fragmentation of IKEv2 messages.
=0A
> =0A
>
=0A
> The IETF datatracker status page for this= draft is:
=0A
> https://datatracker.ietf.org/doc/draft-kampat= i-ipsecme-ikev2-sa-ts-payloa
=0A
> ds-opt/
=0A
> <= /div>=0A
> There are also htmlized versions available at:
=0A<= div>> https://tools.ietf.org/html/draft-kampati-ipsecme-ikev2-sa-ts-pay= loads-opt
=0A
> -04
=0A
> https://datatracker.ietf= .org/doc/html/draft-kampati-ipsecme-ikev2-sa-ts-p
=0A
> ayload= s-opt-04
=0A
>
=0A
> A diff from the previous ver= sion is available at:
=0A
> https://www.ietf.org/rfcdiff?url2= =3Ddraft-kampati-ipsecme-ikev2-sa-ts-paylo
=0A
> ads-opt-04=0A
>
=0A
>
=0A
> Please note that it = may take a couple of minutes from the time of
=0A
> submission= until the htmlized version and diff are available at tools.ietf.org.=0A
>
=0A
> Internet-Drafts are also available by ano= nymous FTP at:
=0A
> ftp://ftp.ietf.org/internet-drafts/
= =0A
>
=0A
>
=0A
> _______________________= ________________________
=0A
> I-D-Announce mailing list
= =0A
> I-D-Announce@ietf.org
=0A
> https://www.ietf.org/= mailman/listinfo/i-d-announce
=0A
> Internet-Draft directories= : http://www.ietf.org/shadow.html or
=0A
> ftp://ftp.ietf.org/= ietf/1shadow-sites.txt
=0A
 
=0A
__________________= _____________________________
=0A
IPsec mailing list
=0AIPsec@ietf.org
=0A
https://www.ietf.org/mailman/listinfo/ipsec=0A
 
=0A
------=_001_NextPart563380421603_=------ From nobody Tue Apr 27 01:29:08 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60EDA3A1A52; Tue, 27 Apr 2021 01:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 GljpptZlTjp6; Tue, 27 Apr 2021 01:29:04 -0700 (PDT) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [IPv6:2a0b:5c81:1c1::37]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23DE43A1A4F; Tue, 27 Apr 2021 01:29:04 -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 EC9871B0019D; Tue, 27 Apr 2021 11:28:58 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1619512139; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=mivFbPtUSnfoq0CDLCmgWuKAT9iExhb3Ux1jyYzyxCA=; b=YKfHu1QP5deI6SoWh7jYCal+ZX8tk9TFX8kEMehyQQnJG6pDfg2EgMesWkDxsi/zLx9QgS IHtLtnwpi0Ak8uTiOEGNBJ0KvO+tD/EKathFGEnx4+u4gOWXYnuCjoYV88GhariYbqoonS snAdzwtXlYTS9X5h4QAmrLy35FHgUH5w2RrFRJSoe/Ea3B8unf7HA+lAACiMqx1ZnpBX6o 8FUPBBnvsYXI409cs1kvDIRILdEccGpmgV0pReP75aO5FHELVVezEvV7DYnAURUelT0CJb xDfm28OI1uEb6im0/KyYgpXpeToHZv431LxAacFMt1wGBpSdLclH8j9UB5OO9w== Received: by fireball.acr.fi (Postfix, from userid 15204) id AF34D25C129C; Tue, 27 Apr 2021 11:28:58 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24711.52042.697210.803423@fireball.acr.fi> Date: Tue, 27 Apr 2021 11:28:58 +0300 From: Tero Kivinen To: ipsec@ietf.org CC: draft-pwouters-ikev1-ipsec-graveyard@ietf.org X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 3 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1619512139; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=mivFbPtUSnfoq0CDLCmgWuKAT9iExhb3Ux1jyYzyxCA=; b=K4UBDqO0qmKQWg1999yq/hHipKr4CPohUSdyd2xEijXXqTNZkhiEIToqNbMsBcDelIuB60 x6I9a082I2vzT1aFB1aPOQWf67PxVO89zE/NankeOGN22hEtL6cpbrg+fZA3Ci8zXQmS+a SoR7aMunMGABoqK4kjARVI4EXiNlStgi+xXA2RuEmWuFi8KaqvO4tu1a0fXyD65Htd5xxz OwJxtu2rf6P1U+r63a1dIQ7RX3txA4z7dp0qG+Q99thkSRPi+qp43od/dvbVY/yfig0KdP s41UQae+ZbU3htgVk6dH1AG+x3kQvfSeRkaOoPYTCeFR9/VGacShKXoTgA60JA== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1619512139; a=rsa-sha256; cv=none; b=mqJ5Z5TtnS57NLnjxWXI3i/VhirbCGk8BIaTY9FHBLSn9ZGtuvwN/pkZpDgRsynUmZFEUR R5oCNnBx8YqQWV1PdTP32xaX5woHmAMhf8P7gL8RVtZ5n6V6xVAGLf2zpW5hMuuhyUkzv4 ugHqCLp3apqzq6sEcn9n5+yyYaB7wvIra2drDBFmj0nV5FZji3GaPCwQS/Xn9/kRNV/i4T WG47YEXmjXoDxI4yYLX8TTXxcSJSrAqweBa4MvB1C0eqS6903vUoyEgJaVz+97nJD4pD1v 9h8oj3GNyPj72WcWqbkQ3apfPZtSYJIZ4XLw6rS8+5vFV8kCCAad103tu0ZXMw== Archived-At: Subject: [IPsec] draft-pwouters-ikev1-ipsec-graveyard adopted by WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2021 08:29:07 -0000 I now closed the WG adoption call and marked this document as adopted by WG. There were some comments requested during adoption call, and I would hope authors would process those and submit next version of the draft as WG document. When I was myself checking the document I noticed that it referes to some completely unrelated RFC 8223 (Application-Aware Targeted LDP) instead of the correct RFC8221 (Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)). At least fix that one before publishing new version of the draft... -- kivinen@iki.fi From nobody Tue Apr 27 07:13:57 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE593A0B07; Tue, 27 Apr 2021 07:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuOsHMQtoycz; Tue, 27 Apr 2021 07:13:54 -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 EDE173A0B0E; Tue, 27 Apr 2021 07:13:53 -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 543AE1B00CF7; Tue, 27 Apr 2021 17:13:51 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1619532831; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=rIdeMlq0m3wPj04F85xHBM8l09PVdIbdDm1YSpDEjz0=; b=fM5ZQ4qyCI2XU8Dm16Fc+HetCtCYv4/V768xp4706rtwowjc780PCwCI+WSeBNpnT0+De0 eFhbr5Kpz8ESBD12NwUlx7mXaHO8WMF1kkTRbmFQL2FkGwG2kWTFhzH1S7xhX1gHxGMvlG U0sr8/9WUfi3y/T9QDRnQD+mESfEo4Kie98RhF5DKq5ffk5FNxbbFBs0xhKMIXU6NjGT5m XRej0iqms47CRKJYbBjBFs7gs6PQHt3gt28xy7duGd1fibOnzCcWNS4iPLzf6J+tEGsN0l GHck5yxBsSyAL1Pjdtc0/hMVLUPNRFzAUA5fOVuD0IrHZkck80kpkLWzJX7KfA== Received: by fireball.acr.fi (Postfix, from userid 15204) id EA82E25C12A0; Tue, 27 Apr 2021 17:13:50 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24712.7198.905751.897464@fireball.acr.fi> Date: Tue, 27 Apr 2021 17:13:50 +0300 From: Tero Kivinen To: draft-ietf-ipsecme-iptfs@ietf.org CC: ipsec@ietf.org X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 26 min X-Total-Time: 26 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1619532831; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=rIdeMlq0m3wPj04F85xHBM8l09PVdIbdDm1YSpDEjz0=; b=b2ONEd43tcacUilVw18dZAMLa74h3y7sBzCnFkn6GxKWDZhW8O1NOZjWnIO5TzHY6M9Q/j SfjEXpHff+k65oJguoB4pxISxctOH7lzCXnQfjJVoEGfw+T6tBvo4+QZENVPVgy4QQw+ls PNggq4GC8Pg2NcApcbmKSs00GCLhaYIXX5jKSLzkga8rXYEBBm/CNl9Twqyu6hZF5KG3W9 Ma6LRW1I0VnIC+/T8WtUaCPeClk5olPnWDUesfFwgYXknnMQd9q4tBaZjHf5Yrr1mzi8di i2ebJKr7EefgLJ8UQwbhfikit17zI9AH+I4cbiFx47Xd76jDEnsLQW1spVVMLQ== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1619532831; a=rsa-sha256; cv=none; b=QE+NgwHPvnzOPAu/1ZfiS9nmNflUNwB6EL+oEpEyI+K3qPsjWc/rbNuXaUOYxXKgaXXTO8 HUbXh78KPIcZPpXvP85X4t6EHMEIZmd2mr8AN+/fSjsFXcO7sLP5VLbaQF52305xr5Iply fSLNRh4heFzbsRwJQKur/hoPOxxgr/A5u2dBXTGrMavnAtdNsAnyBoIAQ+P7WH4CTuh3jq AzltDxqVIS9UcvKYXKpvI9/O54VWGfnNoqAW9mjyON12jqfcV72pLjlNwcu5Y9xcIU0lS6 yIbH7ZsGrRbZftvXyhF1CCdhWAfTB6CHmlHVho2W6CP58rarTgnVm9ANMe14bQ== Archived-At: Subject: [IPsec] Question about the draft-ietf-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2021 14:13:56 -0000 While reviewing the draft for publication I found out that section 2.5 says that we first reorder packets, then make sure we have not missed any packets, and only after that we process the in-order payload streams to extract the inner-packets. The problem is that packet is considered lost only when it falls out of the re-ordering window. This will cause huge delays in the traffic flows every single time we loose even single outer packet. I.e., if we have following flow (O = outer packet n, I = inner packet n), assume packet bandwidth of 10 kB/s, 1400 byte packets, re-order/replay window of 32 (typical for IPsec settings). This means the packet send rate is 7.3 packets per second, and the size of reordering buffer is 4.3 seconds: Time Outer Inner 0.000 O<0> I<1>, pad 0.137 O<1> pad ... 0.411 O<3> pad 0.548 O<4> I<2>, pad 0.685 O<5> pad ... 2.055 O<15> pad 2.192 O<16> I<3>, pad 2.329 O<17> pad ... 3.014 O<22> pad, 3.151 O<23> I<4>, I<5frag1> 3.288 O<24> I<5frag2>, I<6frag1> 3.425 O<25> I<6frag2>, I<7>, pad 3.562 O<26> pad ... 4.247 O<31> pad 4.384 O<32> pad 4.521 O<33> pad Now if the packet O<1> is lost, the algorithm requires us to wait 4.384 seconds (i.e, up to time 4.521), before we can forward I<2> - I<7>, even when they were properly received several seconds before. I think we should allow forwarding the inner packets which are properly and completely received even when we have some earlier packets missing. This will of course also cause traffic to be very bursty in case of packet loss in the inner packets, i.e., instead of getting inner packets in same intervals they were sent, we suddenly receive all of them after the first lost packet drops out of re-ordering queue, i.e., for the final recipient the timing will look like follows: Time: 0.000 I<1> 4.384 I<2> 4.385 I<3> 4.386 I<4> ... I.e., suddenly at 4.384 seconds final recipient will suddenly get burst of back to back packets from the security gateway. This will most likely cause all kind of issues on its own timing algorithms... If we do allow forwarding complete packets in out of order manner, what should we do in case packet O<24> is lost? Should we allow forwarding I<7> immediately when we received O<25>, or do we need to wait 4 more seconds to see whether O<24> ever arrives before we deem both I<5> and I<6> as lost (because fragments of them are lost), and send I<4> and I<7> forward? If we do allow processing of outer packets in that kind of out of order manner, then that will of course mean that there might be reordering happening because of this, and this most likely needs to be mentioned in the draft too. On the other hand I would assume that in normal cases lost packets are much more common than reordered packets, but there are most likely cases where there is lots of reordering, but not that much of lost packets. -- kivinen@iki.fi From nobody Tue Apr 27 08:31:12 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E813A1115; Tue, 27 Apr 2021 08:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMqqzUBK4Bu9; Tue, 27 Apr 2021 08:31:08 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9663F3A1116; Tue, 27 Apr 2021 08:31:08 -0700 (PDT) Received: from ja.int.chopps.org.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 6C556805BF; Tue, 27 Apr 2021 15:31:07 +0000 (UTC) References: <24712.7198.905751.897464@fireball.acr.fi> User-agent: mu4e 1.5.11; emacs 27.2 From: Christian Hopps To: Tero Kivinen Cc: draft-ietf-ipsecme-iptfs@ietf.org, ipsec@ietf.org Date: Tue, 27 Apr 2021 11:23:37 -0400 In-reply-to: <24712.7198.905751.897464@fireball.acr.fi> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [IPsec] Question about the draft-ietf-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2021 15:31:12 -0000 I'm not sure what you mean by Huge delays. Given an example of a 10 kilobit tunnel (really?) means *everything* is super slow, so then reporting raw wall clock times is a bit disingenuous I think. I didn't actually look over the math b/c this just doesn't seem realistic. Have you considered what happens to your inner TCP stream bandwidth when you have regular packet loss, regardless of IPTFS? I think a slight bursty-ness given regular packet loss is the least of your problems at that point. Thanks, Chris. Tero Kivinen writes: > While reviewing the draft for publication I found out that section 2.5 > says that we first reorder packets, then make sure we have not missed > any packets, and only after that we process the in-order payload > streams to extract the inner-packets. > > The problem is that packet is considered lost only when it falls out > of the re-ordering window. > > This will cause huge delays in the traffic flows every single time we > loose even single outer packet. > > I.e., if we have following flow (O = outer packet n, I = inner > packet n), assume packet bandwidth of 10 kB/s, 1400 byte packets, > re-order/replay window of 32 (typical for IPsec settings). This means > the packet send rate is 7.3 packets per second, and the size of > reordering buffer is 4.3 seconds: > > Time Outer Inner > 0.000 O<0> I<1>, pad > 0.137 O<1> pad > ... > 0.411 O<3> pad > 0.548 O<4> I<2>, pad > 0.685 O<5> pad > ... > 2.055 O<15> pad > 2.192 O<16> I<3>, pad > 2.329 O<17> pad > ... > 3.014 O<22> pad, > 3.151 O<23> I<4>, I<5frag1> > 3.288 O<24> I<5frag2>, I<6frag1> > 3.425 O<25> I<6frag2>, I<7>, pad > 3.562 O<26> pad > ... > 4.247 O<31> pad > 4.384 O<32> pad > 4.521 O<33> pad > > Now if the packet O<1> is lost, the algorithm requires us to wait > 4.384 seconds (i.e, up to time 4.521), before we can forward I<2> - > I<7>, even when they were properly received several seconds before. > > I think we should allow forwarding the inner packets which are > properly and completely received even when we have some earlier > packets missing. > > This will of course also cause traffic to be very bursty in case of > packet loss in the inner packets, i.e., instead of getting inner > packets in same intervals they were sent, we suddenly receive all of > them after the first lost packet drops out of re-ordering queue, i.e., > for the final recipient the timing will look like follows: > > Time: > 0.000 I<1> > 4.384 I<2> > 4.385 I<3> > 4.386 I<4> > ... > > I.e., suddenly at 4.384 seconds final recipient will suddenly get > burst of back to back packets from the security gateway. This will > most likely cause all kind of issues on its own timing algorithms... > > If we do allow forwarding complete packets in out of order manner, > what should we do in case packet O<24> is lost? Should we allow > forwarding I<7> immediately when we received O<25>, or do we need to > wait 4 more seconds to see whether O<24> ever arrives before we deem > both I<5> and I<6> as lost (because fragments of them are lost), and > send I<4> and I<7> forward? > > If we do allow processing of outer packets in that kind of out of > order manner, then that will of course mean that there might be > reordering happening because of this, and this most likely needs to be > mentioned in the draft too. > > On the other hand I would assume that in normal cases lost packets are > much more common than reordered packets, but there are most likely > cases where there is lots of reordering, but not that much of lost > packets. From nobody Tue Apr 27 10:52:31 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13633A19DF; Tue, 27 Apr 2021 10:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6xIcxc8x5LI; Tue, 27 Apr 2021 10:52:24 -0700 (PDT) Received: from meesny.iki.fi (meesny.iki.fi [IPv6:2001:67c:2b0:1c1::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FCCE3A19DA; Tue, 27 Apr 2021 10:52:24 -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 meesny.iki.fi (Postfix) with ESMTPSA id 1527A20179; Tue, 27 Apr 2021 20:52:15 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1619545935; 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=C+v1pJLSLmB6q5HrI5GpDuxSdt0szcDthknqUDC+g5w=; b=FQnEcXBzCdEXmK4ilzkuCmYrGGAhQIqXukiSDNs/DhgTh5a1P9oDUzEgOhYrL+NdWFECWL LThHBlUqLUegAAmxj6ECHiHGXsq74MA0ywSqZjlUDzFrN5gbOFtORB3ejcIeylZETDxeQu rM8dqTH/BvrxM0yNOKIwl7l5aZA1Mbo= Received: by fireball.acr.fi (Postfix, from userid 15204) id 4AE7F25C12A0; Tue, 27 Apr 2021 20:52:14 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24712.20302.263889.288737@fireball.acr.fi> Date: Tue, 27 Apr 2021 20:52:14 +0300 From: Tero Kivinen To: Christian Hopps Cc: draft-ietf-ipsecme-iptfs@ietf.org, ipsec@ietf.org In-Reply-To: References: <24712.7198.905751.897464@fireball.acr.fi> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 29 min X-Total-Time: 28 min ARC-Seal: i=1; s=meesny; d=iki.fi; t=1619545935; a=rsa-sha256; cv=none; b=Sw18rVk2fMEFGGbNF5jNV14wPnMxXUHN/6WQa79u82Nh9GPm7JNPysOhKQX56xkQoEG4ez z+7IScwsFe9AbuDNU0Yh0Dj5xLmsf3PDqLmi9xGnll7iYM3v2AZ7RMW901EOj34NwCNOO+ Ds0ZZkIzKvVF9DShSjAepVkuNQS20PE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1619545935; 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=C+v1pJLSLmB6q5HrI5GpDuxSdt0szcDthknqUDC+g5w=; b=yLR15h0JvYZioKUr2ffJwN07c2l0Nxf/9G2MCLcbYe6zzfZGloQXnNPk/w1mM4JjD4Ih0+ gBkGyez5fscHZlQv95yASOJnGk1N7y3WoLNvtqEgbALq0V5KNcRadmSWIJgP3hFZM9X/MK 0q/BUd1xWXJqH8RZP5Z5B4gbqrVwFwg= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [IPsec] Question about the draft-ietf-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2021 17:52:30 -0000 Christian Hopps writes: > I'm not sure what you mean by Huge delays. Given an example of a 10 > kilobit tunnel 10 kilobytes not kilobits, i.e. about 80 kilobits/s. This can handle several low quality audio connections inside, or one high quality uncompressed cd-quality mono channel. > (really?) means *everything* is super slow, so then > reporting raw wall clock times is a bit disingenuous I think. I > didn't actually look over the math b/c this just doesn't seem > realistic. I do not really consider useful to waste bigger bandwidth for single audio connection or similar, and I would assume audio connections is one of those uses cases where proper TFC is useful. Another use case could be terminal connection between servers (text based ssh), I mean I can't really read xterm faster than one kilobytes per second, so this provides 10 times the bandwidth needed for normal terminal connection. I regularly have terminal connections between my devices which lasts for weeks, and I would rather hide the fact when I am actually using them, when I am not using them, but I do not want to allocate tens of % of my home network bandwidth just for that case. 1% would probably be acceptable (100 kilobits/s from the 10 megabits/s inbound connection my VDSL offers). Filetransfers, videostreams etc are not that interesting in the TFC point of view, as they often try to use almost all bandwidth there is (i.e., video stream will use as high quality than what your network connection allows), and those usually have less of privacy concerns. > Have you considered what happens to your inner TCP stream bandwidth > when you have regular packet loss, regardless of IPTFS? I think a > slight bursty-ness given regular packet loss is the least of your > problems at that point. Audio quite often uses UDP. Terminal connections do use TCP, and I do regularly use SSH connections from all over the world to my home server using RTT of 200-300 ms, and you do easily notice couple of second delays when TCP looses packets. Now, when there would be several seconds more just because TFC that would be even more annoying. What kind of bandwidth allocation you would do for audio connection between two end-points? Lets say doorbell audio connection from your door to your home over the mobile phone network? You might not want to outsiders to notice when there is traffic between the gate and home, or even when you start listening the sound from the gate... Also note, that re-ordering and replay window size must be bigger than largest re-ordering time, and sometimes when there are multiple network links involved with bufferbloat etc, those times can be measured in seconds, thus having replay window size of few seconds is not unexpected configuration. This just mean that if you use 100 kbytes/s, i.e., 1 mbit/s bandwidth the replay window size will not be 32, it will be 256 packets, and if you use one megabyte / per second bandwidth it will be 1000 packets etc. I think the 32 packets window size is the minimal setting people use... Of course, as I have been mostly working on the IoT environments and standards lately my view of world is IoT centric, but those devices are one of the devices which could benefit from the better security... -- kivinen@iki.fi From nobody Tue Apr 27 12:07:59 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6483A3A1C65; Tue, 27 Apr 2021 12:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHCTGjFEZLJc; Tue, 27 Apr 2021 12:07:53 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id C75E63A1C4B; Tue, 27 Apr 2021 12:07:41 -0700 (PDT) Received: from ja.int.chopps.org.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 80D7D805BF; Tue, 27 Apr 2021 19:07:40 +0000 (UTC) References: <24712.7198.905751.897464@fireball.acr.fi> <24712.20302.263889.288737@fireball.acr.fi> User-agent: mu4e 1.5.12; emacs 27.2 From: Christian Hopps To: Tero Kivinen Cc: Christian Hopps , draft-ietf-ipsecme-iptfs@ietf.org, ipsec@ietf.org Date: Tue, 27 Apr 2021 15:01:58 -0400 In-reply-to: <24712.20302.263889.288737@fireball.acr.fi> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [IPsec] Question about the draft-ietf-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2021 19:07:57 -0000 For very slow tunnels such as your indicating, you are not worried about out-of-order delivery; just set the reorder window to 0. FWIW, the interest we are aware of is for 1GE to 100GE general purpose tunnels. Thanks, Chris. Tero Kivinen writes: > Christian Hopps writes: >> I'm not sure what you mean by Huge delays. Given an example of a 10 >> kilobit tunnel > > 10 kilobytes not kilobits, i.e. about 80 kilobits/s. This can handle > several low quality audio connections inside, or one high quality > uncompressed cd-quality mono channel. > >> (really?) means *everything* is super slow, so then >> reporting raw wall clock times is a bit disingenuous I think. I >> didn't actually look over the math b/c this just doesn't seem >> realistic. > > I do not really consider useful to waste bigger bandwidth for single > audio connection or similar, and I would assume audio connections is > one of those uses cases where proper TFC is useful. > > Another use case could be terminal connection between servers (text > based ssh), I mean I can't really read xterm faster than one kilobytes > per second, so this provides 10 times the bandwidth needed for normal > terminal connection. I regularly have terminal connections between my > devices which lasts for weeks, and I would rather hide the fact when I > am actually using them, when I am not using them, but I do not want to > allocate tens of % of my home network bandwidth just for that case. 1% > would probably be acceptable (100 kilobits/s from the 10 megabits/s > inbound connection my VDSL offers). > > Filetransfers, videostreams etc are not that interesting in the TFC > point of view, as they often try to use almost all bandwidth there is > (i.e., video stream will use as high quality than what your network > connection allows), and those usually have less of privacy concerns. > >> Have you considered what happens to your inner TCP stream bandwidth >> when you have regular packet loss, regardless of IPTFS? I think a >> slight bursty-ness given regular packet loss is the least of your >> problems at that point. > > Audio quite often uses UDP. Terminal connections do use TCP, and I do > regularly use SSH connections from all over the world to my home > server using RTT of 200-300 ms, and you do easily notice couple of > second delays when TCP looses packets. Now, when there would be > several seconds more just because TFC that would be even more > annoying. > > What kind of bandwidth allocation you would do for audio connection > between two end-points? Lets say doorbell audio connection from your > door to your home over the mobile phone network? You might not want to > outsiders to notice when there is traffic between the gate and home, > or even when you start listening the sound from the gate... > > Also note, that re-ordering and replay window size must be bigger than > largest re-ordering time, and sometimes when there are multiple > network links involved with bufferbloat etc, those times can be > measured in seconds, thus having replay window size of few seconds is > not unexpected configuration. This just mean that if you use 100 > kbytes/s, i.e., 1 mbit/s bandwidth the replay window size will not be > 32, it will be 256 packets, and if you use one megabyte / per second > bandwidth it will be 1000 packets etc. I think the 32 packets window > size is the minimal setting people use... > > Of course, as I have been mostly working on the IoT environments and > standards lately my view of world is IoT centric, but those devices > are one of the devices which could benefit from the better security... From nobody Wed Apr 28 08:41:25 2021 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4146C3A1116; Wed, 28 Apr 2021 08:41:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <161962448020.12575.13131318934919776038@ietfa.amsl.com> Date: Wed, 28 Apr 2021 08:41:20 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev1-algo-to-historic-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2021 15:41:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Deprecation of IKEv1 and obsoleted algorithms Author : Paul Wouters Filename : draft-ietf-ipsecme-ikev1-algo-to-historic-00.txt Pages : 7 Date : 2021-04-28 Abstract: Internet Key Exchange version 1 (IKEv1) is deprecated. Accordingly, IKEv1 has been moved to Historic status. A number of old algorithms that are associated with IKEv1, and not widely implemented for IKEv2 are deprecated as well. This document adds a Status column to the IANA IKEv2 Transform Type registries. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev1-algo-to-historic/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-ikev1-algo-to-historic-00 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev1-algo-to-historic-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 28 08:49:11 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279283A116C for ; Wed, 28 Apr 2021 08:49:09 -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 T6OqITxWYWs4 for ; Wed, 28 Apr 2021 08:49:04 -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 5C3E13A1165 for ; Wed, 28 Apr 2021 08:49:04 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4FVjjV2ccwzKH0 for ; Wed, 28 Apr 2021 17:49:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1619624942; bh=p4xWH76qVU0ZZBR5QRhJ9p7/qtuuuhWcCv/DNF15N1Q=; h=Date:From:To:Subject:In-Reply-To:References; b=LnsMqeLMOqmRu4mmPPeXz3RI6Rhz0qAMPJkbvIjBfjcL6LR7JMMMgA15rgPcjoezk 38VoxQPjQ5IihpfI3fmH/m1Awcv1+ftFuk9KsSi1PxiE0kGFbXAbhQBS8srZFo/urm 5+H8kZjpBVIITiZc2SEa04yauQQD4K2ZebXzgGT8= 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 0fNZNcjRpH23 for ; Wed, 28 Apr 2021 17:49:01 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Wed, 28 Apr 2021 17:49:01 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id DF6ED6029A70; Wed, 28 Apr 2021 11:48:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D3CC666B7C for ; Wed, 28 Apr 2021 11:48:59 -0400 (EDT) Date: Wed, 28 Apr 2021 11:48:59 -0400 (EDT) From: Paul Wouters To: ipsec@ietf.org In-Reply-To: <161962448020.12575.13131318934919776038@ietfa.amsl.com> Message-ID: <40493aa4-ba3a-ad32-fda2-f5ab24d78296@nohats.ca> References: <161962448020.12575.13131318934919776038@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev1-algo-to-historic-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Apr 2021 15:49:09 -0000 On Wed, 28 Apr 2021, internet-drafts@ietf.org wrote: > Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev1-algo-to-historic-00.txt Looks like the datatracker email does not post the diff between different document names :P The diff is: https://tools.ietf.org/rfcdiff?url1=draft-pwouters-ikev1-ipsec-graveyard-06.txt&url2=https://www.ietf.org/archive/id/draft-ietf-ipsecme-ikev1-algo-to-historic-00.txt Basically, it removes the IANA request to close the IKEv1 registries, changes draft name / title to avoid "graveyard" and lists some items as bullet points and sections, and changes some subjective wording to more objective language. I'm not saying this is ready for WGLC, but .... Paul From nobody Thu Apr 29 20:52:39 2021 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1845B3A0C5B; Thu, 29 Apr 2021 20:52:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <161975475704.29468.15663390744493425614@ietfa.amsl.com> Date: Thu, 29 Apr 2021 20:52:37 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc8229bis-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2021 03:52:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : TCP Encapsulation of IKE and IPsec Packets Authors : Valery Smyslov Tommy Pauly Filename : draft-ietf-ipsecme-rfc8229bis-00.txt Pages : 30 Date : 2021-04-28 Abstract: This document describes a method to transport Internet Key Exchange Protocol (IKE) and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as "TCP encapsulation", involves sending both IKE packets for Security Association establishment and Encapsulating Security Payload (ESP) packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP. TCP encapsulation for IKE and IPsec was defined in [RFC8229]. This document updates specification for TCP encapsulation by including additional calarifications obtained during implementation and deployment of this method. This documents makes RFC8229 obsolete. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc8229bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-rfc8229bis-00 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-rfc8229bis-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 29 22:57:56 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83CB3A1365 for ; Thu, 29 Apr 2021 22:57:54 -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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 Nf5Vd0otXLdQ for ; Thu, 29 Apr 2021 22:57:52 -0700 (PDT) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450: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 2FB113A1363 for ; Thu, 29 Apr 2021 22:57:52 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id 12so108089011lfq.13 for ; Thu, 29 Apr 2021 22:57:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=FOuH1cAMNMy0u/M91Hi/msRJ2lF63ab4+JzwhkA2LxQ=; b=HMQOKMgX1IbpZ16Y6C7y7efDkZYYfeGM+HW06E7GPp0xQQqMJVeSHRg3ENfIV/tK+J Qv8kyUFlZzpGRCaN+PG28fBtGOxl6JFfBr9f/QVqOb97JnyeuZpL3V+XtDOVIiSzHnwL cLjNHfbGDs0PQUeAbyrRbTGhpGF6axIKmZKHdZCCgK1yoeIN6615Py6iq16yWpV0Ow9u 73fctjbqIL8XkykNojZBDKrJK16PqUGM7CZBRKqUR/pw9x/u4YcaS/CNykmOJZdWsAfd gljH5n65Ek+Y+5eaosMukJ1KEFQdqF9DJKu8cmKO+8h5VpK2GUh0cP3klnAW+0v6a+6h IXXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=FOuH1cAMNMy0u/M91Hi/msRJ2lF63ab4+JzwhkA2LxQ=; b=TsD3T74V2I83Cx4H4Ee1J6f1ddCpsExu/hcG6yLDIdwRHPsHO+ht75OSeGBF/Z4jpm mXOd2oCIDDuTetzHKckp8PG2YvS/upAOJm9HM7tNxr6mR30s0b17HhOO6r0+krgxf4Hl 3tYIj4uyfWn5jw07h/YVE3xjtrnKup5qytngbv/YUZBDf4PIiiJhLcW8aTJrcL5HJIAw SB6wagAX386Vr0D8BdoKDw9dLC1fe+QRwrg6M+cFQrtEnqpHxxfzA1yq9zp78tNZ3me5 T/zXfqFHkOAfyAA2ppdDB51SvjvE551EdL9+GTWhc49yian4TUQTw/sGNE4PCTRtT8tP 1qbw== X-Gm-Message-State: AOAM532I0baveK8M3tVLJqz/mYUt1ApCzMcoeC/6+TU8+iUUsSCVEJzV POUQk0SLVGCyD3jYZVGfaaoM1axNbfc= X-Google-Smtp-Source: ABdhPJyQXXtZxH4pBe0tLBigKblItJYiO8YVk83ADF3xj+ek+1tt8PFxpPbjb+DJz+Kvlmo8jP56PQ== X-Received: by 2002:a05:6512:1318:: with SMTP id x24mr2098212lfu.376.1619762268840; Thu, 29 Apr 2021 22:57:48 -0700 (PDT) Received: from buildpc ([93.188.44.203]) by smtp.gmail.com with ESMTPSA id 2sm110694ljf.61.2021.04.29.22.57.47 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Apr 2021 22:57:48 -0700 (PDT) From: "Valery Smyslov" To: References: <161975475704.29468.15663390744493425614@ietfa.amsl.com> In-Reply-To: <161975475704.29468.15663390744493425614@ietfa.amsl.com> Date: Fri, 30 Apr 2021 08:57:51 +0300 Message-ID: <0f9001d73d85$c1d9cc60$458d6520$@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: AQMUAMG/33WpiShsg7QYPmr9srFss6hTCakw Content-Language: ru Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc8229bis-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2021 05:57:55 -0000 Hi, the new version of the draft addresses comments from Tero and Paul. Regards, Tommy & Valery. > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. > > Title : TCP Encapsulation of IKE and IPsec Packets > Authors : Valery Smyslov > Tommy Pauly > Filename : draft-ietf-ipsecme-rfc8229bis-00.txt > Pages : 30 > Date : 2021-04-28 > > Abstract: > This document describes a method to transport Internet Key Exchange > Protocol (IKE) and IPsec packets over a TCP connection for traversing > network middleboxes that may block IKE negotiation over UDP. This > method, referred to as "TCP encapsulation", involves sending both IKE > packets for Security Association establishment and Encapsulating > Security Payload (ESP) packets over a TCP connection. This method is > intended to be used as a fallback option when IKE cannot be > negotiated over UDP. > > TCP encapsulation for IKE and IPsec was defined in [RFC8229]. This > document updates specification for TCP encapsulation by including > additional calarifications obtained during implementation and > deployment of this method. This documents makes RFC8229 obsolete. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc8229bis/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ipsecme-rfc8229bis-00 > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-rfc8229bis-00 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Apr 30 08:58:31 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE2203A1D6F for ; Fri, 30 Apr 2021 08:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOjo6suXsCCT for ; Fri, 30 Apr 2021 08:58:27 -0700 (PDT) Received: from meesny.iki.fi (meesny.iki.fi [IPv6:2001:67c:2b0:1c1::201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 906263A1D6E for ; Fri, 30 Apr 2021 08:58:27 -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 meesny.iki.fi (Postfix) with ESMTPSA id 8FE4C20EC2; Fri, 30 Apr 2021 18:58:21 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1619798301; 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=XrNo22zPy7L8zy6OF9lVkMBMmDfFLISGQiZJhfsZHg8=; b=McNTqhRyvccID3EF9nADbNq9h9Aqk1wwrDLM8G/O9W06C9z+77tsGa8xpcRJdqTF138fQb INEoABidjKlzt059bkZAVOU6l3J1lGIP2qvf5IRGrQYZo3caPfbPVSxFlPUEgcscns4/1d lrVaQ8feZVvbJK86ED1hl7x+MRhNGjs= Received: by fireball.acr.fi (Postfix, from userid 15204) id 2521825C12A7; Fri, 30 Apr 2021 18:58:21 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24716.10525.101692.724097@fireball.acr.fi> Date: Fri, 30 Apr 2021 18:58:21 +0300 From: Tero Kivinen To: Christian Hopps Cc: ipsec@ietf.org In-Reply-To: References: <24712.7198.905751.897464@fireball.acr.fi> <24712.20302.263889.288737@fireball.acr.fi> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 7 min X-Total-Time: 247 min ARC-Seal: i=1; s=meesny; d=iki.fi; t=1619798301; a=rsa-sha256; cv=none; b=WPfJmLugmEQys2QK+eI4MqfC3+vQVbhkDkFWOPfM5OcxD7/xzagojIRUv4HBC8Ys4/I9tD 7jwBseqmushnIoZJfZjimiBzPqPF39r4LGPHv/Q57+CuStL5pZtagorNQicAS/CRhHgOCJ NinKqH2GfPnsQL/Xqjpx2p+7tunfdFk= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1619798301; 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=XrNo22zPy7L8zy6OF9lVkMBMmDfFLISGQiZJhfsZHg8=; b=ZbdcZ6U6hPKXahQtOn/sE5VT3Efoz/WylGa8JQek2JY0Sxqj8Jw5GApuaz8u+wS1mUrLAa DMxxJyhQcv+s/YDeNCppJfbh2KRL96D4gcEmUDdCWLP+wUl2xbFc9tLW1Zzp/V12lioVWn lS5t6y6HeMhemoWtaMqIxy8fIKaBOzI= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [IPsec] Question about the draft-ietf-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2021 15:58:30 -0000 Christian Hopps writes: > > For very slow tunnels such as your indicating, you are not worried > about out-of-order delivery; just set the reorder window to 0. We do care about the replays even when we do not care about reorder, so setting reorder window to 0 is not acceptable, as that would effectively also set the replay window to 0, and this > FWIW, the interest we are aware of is for 1GE to 100GE general > purpose tunnels. I assume 1GE, means 1Gbit/s speed, i.e., with 1400 byte packets that means about 100k packets per second, and with 1000 packet replay window (which would be appropriate with that fast link), that means each packet drop adds 1/100 s = 10ms delay until the reorder window clears. Anyways I think this should be mentioned in the draft, even if you do not want to allow sending packets out as they come in, but delay and buffer each packet until window clears. -- kivinen@iki.fi From nobody Fri Apr 30 09:18:35 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C983A1E0D for ; Fri, 30 Apr 2021 09:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MX9HP1yhtzgx for ; Fri, 30 Apr 2021 09:18:28 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9898B3A1E0B for ; Fri, 30 Apr 2021 09:18:28 -0700 (PDT) Received: from smtpclient.apple (047-026-251-217.res.spectrum.com [47.26.251.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 106A280E70; Fri, 30 Apr 2021 16:18:27 +0000 (UTC) From: Christian Hopps Message-Id: <9A890539-3999-4760-B029-C5628FFBD385@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_24259B8B-C61F-4BBE-B412-39A2CFD6D0C5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Fri, 30 Apr 2021 12:18:26 -0400 In-Reply-To: <24716.10525.101692.724097@fireball.acr.fi> Cc: ipsec@ietf.org To: Tero Kivinen References: <24712.7198.905751.897464@fireball.acr.fi> <24712.20302.263889.288737@fireball.acr.fi> <24716.10525.101692.724097@fireball.acr.fi> X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: Re: [IPsec] Question about the draft-ietf-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2021 16:18:33 -0000 --Apple-Mail=_24259B8B-C61F-4BBE-B412-39A2CFD6D0C5 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii The replay window does not need to be the same size as the reorder window. Thanks, Chris. > On Apr 30, 2021, at 11:58 AM, Tero Kivinen wrote: > > Christian Hopps writes: >> >> For very slow tunnels such as your indicating, you are not worried >> about out-of-order delivery; just set the reorder window to 0. > > We do care about the replays even when we do not care about reorder, > so setting reorder window to 0 is not acceptable, as that would > effectively also set the replay window to 0, and this > >> FWIW, the interest we are aware of is for 1GE to 100GE general >> purpose tunnels. > > I assume 1GE, means 1Gbit/s speed, i.e., with 1400 byte packets that > means about 100k packets per second, and with 1000 packet replay > window (which would be appropriate with that fast link), that means > each packet drop adds 1/100 s = 10ms delay until the reorder window > clears. > > Anyways I think this should be mentioned in the draft, even if you do > not want to allow sending packets out as they come in, but delay and > buffer each packet until window clears. > -- > kivinen@iki.fi > --Apple-Mail=_24259B8B-C61F-4BBE-B412-39A2CFD6D0C5 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+m1FHa6lLh2DDte4MCUFAmCMLdIACgkQLh2DDte4 MCXzdw/8CmxlNI0vOzAxoFNSDj/D5VMKVl5HauhIGClXQruCr/pWtcvxOsaVTl55 VAaDQ3KIemcnvOzFazchTqdItRWdGqeFIpLs5ZCDH5xLgxiLNAe/Lke4Uoq9tfx9 pPCgGXtsEW2xbufYdBzVhCq11P8On+u9daMxGz148LPWWf45eACt2S7utKJGe2zK e2l2yljbzLTqquaSTfvykRnxG+l2FqxySGJjjKzbbkIMVmkQn3dJpQfnTzFUZ7q4 dXDiXpZQpyNLkox9RQH82rVQdEJgbaB1ddarqw/TAvuHrKKkcGFWB2jMyxmdt6GS qz1qUmDM5nrLKwqXV4mNDs7GNJZIDEXWJ75gUakqkcFnAOW6i5AqxLvFjZ0KIm24 BSxW58sGdeCu9gbACza10HbJ+MvtoA0bsk8dCM3Fd+ne6S0hvyx3AdeO6h242Syw osnQwKeMbvUDcnamAa2N5rmL1mdgvQqkhJ+6Rzlh2uIFQW2DRT1nlbxm3LWeyms2 IQb88vjcwn28xrY4CvpHPzAkvpdNC6CBDwNXBS0TyOpuF+72ACABKJdGpGT94xH5 BGHwpaZkTUxKtlk3xis1GvwBx+GSRp87lB1pjHK+felBZ7+yUKCZT/yBuRFRWIxX FRFeNGBxOaYkF4G5U6LJh8KuW7nqg6fHSP3ewxrf0fQxeIgJGXc= =2Lqk -----END PGP SIGNATURE----- --Apple-Mail=_24259B8B-C61F-4BBE-B412-39A2CFD6D0C5--