From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D416EC47404 for ; Fri, 11 Oct 2019 13:24:57 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 6CB7D2089F for ; Fri, 11 Oct 2019 13:24:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6CB7D2089F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B93B81EAE9; Fri, 11 Oct 2019 15:24:56 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 320CE1EADD for ; Fri, 11 Oct 2019 15:24:55 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Oct 2019 06:24:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,284,1566889200"; d="scan'208";a="197578502" Received: from irsmsx151.ger.corp.intel.com ([163.33.192.59]) by orsmga003.jf.intel.com with ESMTP; 11 Oct 2019 06:24:52 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.164]) by IRSMSX151.ger.corp.intel.com ([169.254.4.234]) with mapi id 14.03.0439.000; Fri, 11 Oct 2019 14:24:51 +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+B25omiU24dVUeLGfYdKdT6yIAgAAwubA= Date: Fri, 11 Oct 2019 13:24:51 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772580191975980@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> 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: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiY2UxZmJjN2YtNGI4Yi00ZDQ0LTk1NjAtNDU0YjU5Yjk2MGQxIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiaUxHbTZwRlFXT0F1czRYS0pKYWxBd1RDaUJYdUg5QVlLXC9YY3I2WndUTzRyOVhZaGRqSUtjXC9mejFRMnVcL3NFbCJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [163.33.239.181] 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" Hi Akhil, > > Ipsec-secgw example application fails to initialize when using default > > 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 initialized, > > 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 IPv6. > > > > 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 correct > > SAD (IPv4 or IPv6) in places where previously combined database was > > passed. >=20 > Can we have 2 different SAs with same SPI value and with different IPv4 a= ddresses? >=20 > Will the IPSec library be able to handle this case. With Setkey it is pos= sible in linux. > Now that we have IPSEC library we should be compatible with what linux ca= n 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 patch= . 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. >=20 > So splitting the SADB with IPv4 and IPv6 will just avoid the issue for IP= v4 and IPv6 but the > Issue will still be there. > I believe this should be fixed in library rather than application maintai= ning > Two different databases. Library's intent is to reduce the application ov= erhead for maintaining > IPSec specific stuff. Probably we didn't put enough effort to describe the patch goals and method= s. 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 to th= e same SPI (SA), in other it doesn't. =20 So for same config-file ipsec-secgw can either fail or not depending on - legacy/library mode - selected security action type =20 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 sport= 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 a= ble 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 SIP/D= IP values) at SA creation time. The way ipsec-secgw obtains that information - search for given SPI value a= cross SPDs (IPv4 and IPv6). So when it finds entries in both IPv4 and IPv6 it is not clear which one 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 that would be referred by both SPD tables (current situation),=20 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. =20 =20 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 >=20 > > > > Split of SA entries is done at initialization stage. Most of given SA > > entries are checked against SPD. If matching entry is in IPv4 SPD, SA > > rule is added to IPv4 SAD (respectively for IPv6). Different splitting > > method is used only when SA entry is for tunnel in inbound direction. > > In that case if IPv4 tunnel should be used, SA entry is added to IPv4 > > SAD (respectively for IPv6). Reasoning is that inner IP version can > > be different than outer IP version for tunneled traffic. > > > > Bugzilla ID: 239 > > Fixes: 5a032a71c6d3 ("examples/ipsec-secgw: make app to use IPsec libra= ry") > > > > Reported-by: Lukasz Bartosik > > Signed-off-by: Mariusz Drost > > --- > > examples/ipsec-secgw/ipsec-secgw.c | 48 ++-- > > examples/ipsec-secgw/ipsec.c | 5 +- > > examples/ipsec-secgw/ipsec.h | 21 +- > > examples/ipsec-secgw/sa.c | 396 ++++++++++++++++++++--------- > > 4 files changed, 312 insertions(+), 158 deletions(-) > >