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 71C5CA3160 for ; Fri, 11 Oct 2019 16:02:05 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A501B1EAED; Fri, 11 Oct 2019 16:02:04 +0200 (CEST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00065.outbound.protection.outlook.com [40.107.0.65]) by dpdk.org (Postfix) with ESMTP id E6F901EAEA for ; Fri, 11 Oct 2019 16:02:02 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W2ebwsUvMqBN2LUsGERtvfF6zU710Jh9uORnAXs2k8uOAfFjA/kNG2sblhUzxCB4nqLwPtpza7l66BZqewQCL46s7prZvoaAS8wgz7ezoI0070fOE7OYfg3PiaMTSiQBu0nXiOOUB2/zEdjr+RTbIEHAHz1+qsxcLiJUE0PuuCWHI95xXipC69tUFV+NA5UDqFHUNRlt5qWbDx4Z/eKSIxv2s9JHPPJ53RIEjfL13nTODskRrvs6sZJ9Pc/mR9xTSFqnazLnJtfP1lhSMQSPnYQ/cAjaWmME/egHPmg4wrNIAeHsEsNw6lHqJ9hjREiK6t7BIdbG+J/3E8q8Qm9n/Q== 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=R8Or5a9DqTF0wrvKEwkB1z1KyQUdXDvoW5UBXZTQEiM=; b=Yk5OF2f7+Je2NHaKSn8KP+6Z4HWH9u06L5AKGDb0VAMXtnuuoe3tA72nNNvduT9j+ciHjzOzzrB4SP22Q7DvolJ/ueamYSJ1aD2Y1Js/ViJoDNugT7Y/W38i6ocEncBrPJa/En3lDIojPq4UlL23mzEzaMM42IRdsA0D7Jk4rWLTRJAIlpR80lOKULos+mdcCarJhsML/aIktfiSHeFaQcwVzJIviUoBipvyHycaDfwV2+YTmgJRC2BjLMG80hti7ZxCFFp4xj97O0Y/InMFTjcIoMbHUs7m5+eO9qCRbnbKXMFnftd+08TbSirz2rzPv5v5Pse5UCP0h/Tc9HNWxg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=R8Or5a9DqTF0wrvKEwkB1z1KyQUdXDvoW5UBXZTQEiM=; b=Y79Vb/hGQ9UWaF1a3ZsHBHXb6U5C47QnN/RHIGuK9xOrKpz4XzwdOu7BfxYPyYRAhIkjuxlFJQPlQa6TugNBgw2udMIlAaMEygtKCNiYqLj/Cm3OhVYJHvx9x1v4djitmgG5OWyAGoHIXUGmZIaDvd0s6B5XFkBQydMhwDyoa8o= Received: from VE1PR04MB6639.eurprd04.prod.outlook.com (10.255.118.11) by VE1PR04MB6543.eurprd04.prod.outlook.com (20.179.235.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.17; Fri, 11 Oct 2019 14:02:02 +0000 Received: from VE1PR04MB6639.eurprd04.prod.outlook.com ([fe80::c045:5df2:ba1f:c3ee]) by VE1PR04MB6639.eurprd04.prod.outlook.com ([fe80::c045:5df2:ba1f:c3ee%5]) with mapi id 15.20.2347.021; Fri, 11 Oct 2019 14:02:02 +0000 From: Akhil Goyal To: "Ananyev, Konstantin" , "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: AQHVcsP1lt53B9uVGE6M+I+uUDtHm6dT+Z4AgAGPX4CAAAaIQA== Date: Fri, 11 Oct 2019 14:02:01 +0000 Message-ID: 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: <2601191342CEEE43887BDE71AB9772580191975980@irsmsx105.ger.corp.intel.com> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=akhil.goyal@nxp.com; x-originating-ip: [92.120.1.65] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5ae68a29-759b-47e8-1a14-08d74e539716 x-ms-office365-filtering-ht: Tenant x-ms-traffictypediagnostic: VE1PR04MB6543: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5516; x-forefront-prvs: 0187F3EA14 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(4636009)(39860400002)(366004)(136003)(346002)(376002)(396003)(189003)(199004)(9686003)(6436002)(6306002)(6246003)(446003)(11346002)(486006)(476003)(55016002)(4326008)(7736002)(7696005)(86362001)(66446008)(66556008)(66476007)(256004)(66946007)(64756008)(14444005)(26005)(316002)(74316002)(54906003)(76116006)(6506007)(102836004)(81166006)(81156014)(76176011)(8676002)(52536014)(186003)(110136005)(99286004)(305945005)(33656002)(966005)(71190400001)(71200400001)(6116002)(3846002)(8936002)(25786009)(5660300002)(44832011)(14454004)(66066001)(2906002)(229853002)(478600001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:VE1PR04MB6543; H:VE1PR04MB6639.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: phLYvR3spXdyQgiY+QVtA/6Yki4D3WFPGTsIsEDdFgt9uExe8osr4se3QSl0rLMFY8dTETZcSeB0AI9IKnRmMLtHihNq4WPFBGzSBK5z5zHSgZmzIScaRPXbO9ovcCNViT4YOAu/hYy+XhCRZne/2cFm8J/RV3RCcDf8Ns90QYEl1zoEj/kZAGtB0xe8Yh1TfLhJxhB4RmuvBU+bHliQ/hA/XziBflrW857AQh2wfXesb98ci34mY/8qM60mLQa79XQBTrORGu1H30cADwHlbYLum2XdH8a7DbxXglNiUgycE0oVPGGTng8nHMYLeHRhbGANUt/kFuOWdF7VJ9Dl7DC8Z93WddurIv9XmglxqCBnh5aIAc7bcMT6ovRrr+08IUxFEH94IkDLoXasGIwEe209jS07tjAQHbE505+trgN+MegSOsuBuTzpOiGZVylzXyqxBVNIK3NoNN7A6kkSlA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5ae68a29-759b-47e8-1a14-08d74e539716 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2019 14:02:01.9455 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: SU+pqIy5CzRGQ5Fze6YhC8/g47Pchn+zsuYUt3fsmrZexc5sRuEdk5EL5dC3RdVtHXrsSI/L9nzBDqqyJA2qyw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR04MB6543 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 Konstantin, >=20 > Hi Akhil, >=20 > > > Ipsec-secgw example application fails to initialize when using defaul= t > > > 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 initialize= d, > > > 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 o= ne > > > 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. > > > > Can we have 2 different SAs with same SPI value and with different IPv4 > addresses? > > > > Will the IPSec library be able to handle this case. With Setkey it is p= ossible in > linux. > > Now that we have IPSEC library we should be compatible with what linux = can > do. >=20 > 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 pat= ch. > We aim for 19.11 right now but might slip to 20.02. >=20 > 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 = IPv4 and > IPv6 but the > > Issue will still be there. > > I believe this should be fixed in library rather than application maint= aining > > Two different databases. Library's intent is to reduce the application = overhead > for maintaining > > IPSec specific stuff. >=20 > Probably we didn't put enough effort to describe the patch goals and meth= ods. > 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 = 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 >=20 > As an example with config file: >=20 > sp ipv4 in esp protect 11 pri 2 src 192.168.0.0/16 dst 192.168.0.0/16 spo= rt > 0:65535 dport 0:65535 > sp ipv6 in esp protect 11 pri 2 src fd12:3456:789a:0031:0000:0000:0000:00= 92/64 > dst fd12:3456:789a:0031:0000:0000:0000:0014/64 sport 0:65535 dport 0:6553= 5 > 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 >=20 > library mode would fail to start, legacy mode would start but wouldn't be= able to > work correctly. >=20 > That is the issue that Lukasz reported: > https://bugs.dpdk.org/show_bug.cgi?id=3D239 >=20 > The reason for that: in some cases we do need to know SA IP type (and SIP= /DIP > values) at SA creation time. > The way ipsec-secgw obtains that information - search for given SPI value= across > 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), > 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. >=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. 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 n= ot fixing it. Rather it is just avoiding it. I have seen the patch for the SAD suppor= t in IPSEC. That is the correct solution and we should pursue that. When you have that = logic in place You would be replacing this code entirely. You have time till RC2. Application patches are acceptable till RC2 which i= s close to 3 weeks from now. Regards, Akhil