From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8012CA3160 for ; Fri, 11 Oct 2019 18:38:50 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 47B241EB11; Fri, 11 Oct 2019 18:38:50 +0200 (CEST) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id 758B01EAED for ; Fri, 11 Oct 2019 18:38:48 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Oct 2019 09:38:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,284,1566889200"; d="scan'208";a="193579963" Received: from irsmsx106.ger.corp.intel.com ([163.33.3.31]) by fmsmga008.fm.intel.com with ESMTP; 11 Oct 2019 09:38:46 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.164]) by IRSMSX106.ger.corp.intel.com ([169.254.8.184]) with mapi id 14.03.0439.000; Fri, 11 Oct 2019 17:38:45 +0100 From: "Ananyev, Konstantin" To: Akhil Goyal , "Drost, MariuszX" , "Nicolau, Radu" CC: "dev@dpdk.org" , Lukasz Bartosik Thread-Topic: [PATCH v2 1/2] examples/ipsec-secgw: fix SAD selection logic Thread-Index: AQHVcsP3rs+B25omiU24dVUeLGfYdKdT6yIAgAAwubCAAWbBgIAAO2lw Date: Fri, 11 Oct 2019 16:38:44 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772580191975C03@irsmsx105.ger.corp.intel.com> References: <20190905123523.172-1-mariuszx.drost@intel.com> <20190924103539.12052-1-mariuszx.drost@intel.com> <20190924103539.12052-2-mariuszx.drost@intel.com> <2601191342CEEE43887BDE71AB9772580191975980@irsmsx105.ger.corp.intel.com> In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMzJmZDZjYzYtZGU2Yy00NWMyLThhYTItZTAyOWU5YWUzYTQ1IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoibUQ4dlI1QmtBZjlRRk9zVGYwXC9TeU5IaCtQcVV6UFBIVm5pZXV4QzRLYTJvU0hFajlpS0EwS2J2OXNQcU5vTXAifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2 1/2] examples/ipsec-secgw: fix SAD selection logic X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > > > > Ipsec-secgw example application fails to initialize when using defa= ult > > > > configuration file (ep0.cfg) in library mode (librte_ipsec enabled)= . > > > > > > > > The reason is that two of SP rules in ep0.cfg, one for IPv4 and one > > > > for IPv6, are using the same SPI number. When SA rules are initiali= zed, > > > > their SPI number is checked against SPIs stored in SPD. For library > > > > mode, it is not allowed for the same SA to handle both IPv4 and IPv= 6. > > > > > > > > Solution is to split SAD into two separate parts - one for IPv4 and= one > > > > for IPv6. Usage of SAs stays the same. Only change is to pass corre= ct > > > > SAD (IPv4 or IPv6) in places where previously combined database was > > > > passed. > > > > > > Can we have 2 different SAs with same SPI value and with different IP= v4 > > addresses? > > > > > > Will the IPSec library be able to handle this case. With Setkey it is= possible in > > linux. > > > Now that we have IPSEC library we should be compatible with what linu= x can > > do. > > > > For sure, SADB implementation has to be inside librte_ipsec. > > In fact Vladimir submitted patches for that: > > http://patches.dpdk.org/cover/60910/ > > I think we already looked at them. > > We also plan to integrate it into ipsec-secgw, it would be a separate p= atch. > > We aim for 19.11 right now but might slip to 20.02. > > > > This patch is not about improve/change ipsec-secgw SAD implementation, > > see description below. > > > > > > > > So splitting the SADB with IPv4 and IPv6 will just avoid the issue fo= r IPv4 and > > IPv6 but the > > > Issue will still be there. > > > I believe this should be fixed in library rather than application mai= ntaining > > > Two different databases. Library's intent is to reduce the applicatio= n overhead > > for maintaining > > > IPSec specific stuff. > > > > Probably we didn't put enough effort to describe the patch goals and me= thods. > > Let me try again: > > Right now there is an inconsistency in ipsec-secgw behavior. > > In some cases it allows two different IPv4 and IPv6 SP rules to refer t= o the same > > SPI (SA), > > in other it doesn't. > > So for same config-file ipsec-secgw can either fail or not depending on > > - legacy/library mode > > - selected security action type > > > > As an example with config file: > > > > sp ipv4 in esp protect 11 pri 2 src 192.168.0.0/16 dst 192.168.0.0/16 s= port > > 0:65535 dport 0:65535 > > sp ipv6 in esp protect 11 pri 2 src fd12:3456:789a:0031:0000:0000:0000:= 0092/64 > > dst fd12:3456:789a:0031:0000:0000:0000:0014/64 sport 0:65535 dport 0:65= 535 > > sa out 11 cipher_algo null auth_algo null mode transport > > sa in 11 aead_algo aes-128-gcm \ > > aead_key de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef \ > > mode transport port_id 0 type inline-crypto-offload > > > > library mode would fail to start, legacy mode would start but wouldn't = be able to > > work correctly. > > > > That is the issue that Lukasz reported: > > https://bugs.dpdk.org/show_bug.cgi?id=3D239 > > > > The reason for that: in some cases we do need to know SA IP type (and S= IP/DIP > > values) at SA creation time. > > The way ipsec-secgw obtains that information - search for given SPI val= ue across > > SPDs (IPv4 and IPv6). > > So when it finds entries in both IPv4 and IPv6 it is not clear which on= e to use and > > exits with an error. > > To avoid such situation that patch does the following: > > - search for given SPI value across both SPDs (IPv4 and IPv6) > > - for each positive result create a new SA. > > So if we have same SPI in both IPv4 and IPv6 SPDs instead of one SA tha= t > > would be referred by both SPD tables (current situation), > > we will create 2 independent SAs - one for IPv4, second for IPv6. > > For each one a separate rte_security/crypto session will be created and > > programmed. > > > > As side effect of that - we have to split ipsec-secgw SADB into two, > > as right now it is just a raw array indexed by (SPI%N) value. >=20 > I got the intent of this patch in first place. > I agree that there is a bug in the current application, but this patch is= not fixing > it. Rather it is just avoiding it. I have seen the patch for the SAD supp= ort in IPSEC. > That is the correct solution and we should pursue that. When you have tha= t logic in place > You would be replacing this code entirely. > You have time till RC2. Application patches are acceptable till RC2 which= is close to > 3 weeks from now. Ok, so to confirm: Your only issue here is that patch is that we have to split ipsec-secgw SAD= B into two? No objections to other part: - search for given SPI value across both SPDs (IPv4 and IPv6) - for each positive result create a new SA. So if we have same SPI in both IPv4 and IPv6 SPDs instead of one SA that would be referred by both SPD tables (current situation), we will create 2 independent SAs - one for IPv4, second for IPv6. For each one a separate rte_security/crypto session will be created and pro= grammed. ? Because, I think that part will still be needed even when will have new SAD= in place. Konstantin