From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 3FB40A0A02; Wed, 24 Mar 2021 11:39:49 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2E69A4067B; Wed, 24 Mar 2021 11:39:49 +0100 (CET) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by mails.dpdk.org (Postfix) with ESMTP id 662354014F for ; Wed, 24 Mar 2021 11:39:47 +0100 (CET) IronPort-SDR: BaotQVgWUEYk6uByof6LrfGaxSih96HIhW7bETOs+Th4s30jRrd3uUVgrI36q9eIbR9WE95F7t zL8415NJzisA== X-IronPort-AV: E=McAfee;i="6000,8403,9932"; a="170650686" X-IronPort-AV: E=Sophos;i="5.81,274,1610438400"; d="scan'208";a="170650686" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Mar 2021 03:39:46 -0700 IronPort-SDR: SK8kEsbJhEKCKVwHFjDBJ4f66L+YqoSWaK6TTOP/ZknD8nx6djgWbB8STa9JjBKbvLCkkah28o DuP6+V3BSyzQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.81,274,1610438400"; d="scan'208";a="415426676" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by orsmga008.jf.intel.com with ESMTP; 24 Mar 2021 03:39:46 -0700 Received: from fmsmsx609.amr.corp.intel.com (10.18.126.89) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 24 Mar 2021 03:39:45 -0700 Received: from fmsmsx608.amr.corp.intel.com (10.18.126.88) by fmsmsx609.amr.corp.intel.com (10.18.126.89) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 24 Mar 2021 03:39:45 -0700 Received: from FMSEDG603.ED.cps.intel.com (10.1.192.133) by fmsmsx608.amr.corp.intel.com (10.18.126.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2 via Frontend Transport; Wed, 24 Mar 2021 03:39:45 -0700 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (104.47.38.56) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2106.2; Wed, 24 Mar 2021 03:39:44 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CfStdJWCihpBAL5K4HiGEyfPVUb12bzFjrYnIJtHzovpKn9KECXcqtJY361X0gPIS6usZHox4e0sd13WC7p+GUdAioIbOh2suhZ0kITbkZQtYXMW74BCXqmPjbUl0CzSDfypfYGL3//TkB08Icfbs/x5yX7c7jeCJAqSJIovSBHGuFW1b40YNwWgf45lgQxT6gwRdf5nmNg1Vy78xQ0HMTHdciaU07JbMvRDzz14CazoOM3TJUJ2SP2tVcNpM/Sx/AkajvBjQyFhE7au0jfbaxEl0QxRdv0zTt6eC5ftbrH9TYhDTMk9jbrMd/cskRrVNMQa4sffCsZDh/Cpoa7s4Q== 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=a+G9Z9J4xM6gvb/FQbdQKHOW5xWWOzonetjwGCMJ5MI=; b=YmACiqbvPG1d0BsCJdi4UYeqh+7URLN3D3TBsEC66JcTw7cLpenvWl7VHRkZenUUYlchAnVX+ZN6bXoNoG0u/mAL6j7WvA/PLab1fqLrWQ//y9Ux8X5gJr9tRseAKpFP8c9htYgp13DYIfgeCD5MIV1chsWsg5m3qwfj8ZHbzw85xAfrT0ArZwwOjkimoHjvrBaylp6Z6Dcm6vwhUEzTUXaLQEbGi2JrDkpDu3KvKWnOnlcnrUvYW7bhQPK1YaElCWFUok8zG5ahWA0IugcM1kaSvPIJXaBJRP71roPZK2thO/WKE5XMCWpYN+bBKy57vIpd4fs9ZTrsyCivnL0nfg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=a+G9Z9J4xM6gvb/FQbdQKHOW5xWWOzonetjwGCMJ5MI=; b=UgEyvNim/tElADbV/eL185ITbkteBQJuQ4KOntaVvmSR1QLgvmOg6mC+p5DTc4PIcy8cKycnF751L67E36NQXL5S45Z85hJgMP5f5WD92/ZTIUJMCwOqyRuWLtLUcW1UAsF4p+bgIE1IJNPpUTjbW83HmUX3hqzzLoWxo4NEmsI= Received: from DM6PR11MB4491.namprd11.prod.outlook.com (2603:10b6:5:204::19) by DM6PR11MB2953.namprd11.prod.outlook.com (2603:10b6:5:6a::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.24; Wed, 24 Mar 2021 10:39:42 +0000 Received: from DM6PR11MB4491.namprd11.prod.outlook.com ([fe80::3182:6da2:8c64:f07a]) by DM6PR11MB4491.namprd11.prod.outlook.com ([fe80::3182:6da2:8c64:f07a%3]) with mapi id 15.20.3955.027; Wed, 24 Mar 2021 10:39:42 +0000 From: "Ananyev, Konstantin" To: Tejasree Kondoj , Akhil Goyal , "Nicolau, Radu" CC: Anoob Joseph , Ankur Dwivedi , Jerin Jacob Kollanukkaran , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH 2/3] examples/ipsec-secgw: add UDP encapsulation support Thread-Index: AQHXGX88kpfR1IrPZ0aUAC3IvRtRz6qLijxggAW4eYCAAGgxgIAADjEAgAAJfvCAACWOgIABCdGAgAAFovA= Date: Wed, 24 Mar 2021 10:39:42 +0000 Message-ID: References: <20210315103616.31364-1-ktejasree@marvell.com> <20210315103616.31364-3-ktejasree@marvell.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.5.1.3 authentication-results: marvell.com; dkim=none (message not signed) header.d=none;marvell.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [109.255.184.192] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5c0f9d75-32ed-4463-2787-08d8eeb1225a x-ms-traffictypediagnostic: DM6PR11MB2953: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: TnicTOZIMvrB9vvgBqdhjAzFAUK6mbCU/Km8dOrFSFzSEp8VZQrcfff6mIJ7CI5wzh+c1BzhTdJcLD7NcGkBgu8ifa+LHQlxCWlGxXui6tjw0u40CFeDY/RX7NW7i2GC4ZiaRlL5hIY+oeMs5x/k9fed08QnhWt/r4J2wEBHTOxqsqjBbGlRpm8eaSxgiwy8Tqpy3Fg/E643G8H1iNqazRGS1XfaBlUtb69I1X6O9fR1BFSQAEESSbVaMrzuKsEaBrlcRiB7ZFY59xFQts3imrYDqivVYvpejU1H+myv+YiHcxIwVitDFi/yjPUtQYNlR5VXhl7HzowqN0TAUDqUlLwRFTUq3TpB0YTWiE4hMuI+lA7403mCZYkGVIASBFg1LsOd7X2J4X5T4F6sVxPQkB64FfoERirKAmhrnkc1TLUdclMVUX4nAnwjVDTV0GORE7vrN/kdpcyFi05dUvvvGEBjyMtjbVwFnwNSSizN0e3AT6OY0AEahYF2aylXCmVPt31djQjQVYjoY+dFOVZeNC7p8nZdOOhMP+J4RehFMSbaXB2MrqZK/fG7Dp+dSLz/tcrAKWoly/NdidMipTFSD96PC4LoXgRjkS63DITN0oJIRyrBVUDySDzGnlGGeOq7O9tXnR6+cqVf+dbMO8ZxF4moY+lLtHGxnZ7pLvUYSX0= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB4491.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(366004)(376002)(396003)(346002)(39860400002)(38100700001)(8676002)(6636002)(6506007)(26005)(55236004)(478600001)(186003)(7696005)(316002)(8936002)(5660300002)(52536014)(71200400001)(4326008)(66476007)(64756008)(55016002)(66446008)(66946007)(76116006)(2906002)(9686003)(86362001)(83380400001)(110136005)(54906003)(66556008)(33656002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?Ah53GO8vaY73GHxYWva2or9F+57C4P3CGmhu025zgCuakG2BJpfLlovEsR0/?= =?us-ascii?Q?mwmE1Jz62Lk8DpaLIkUNRiKmc9W0ZR3ju6xdxxZni+p2S53YvlDnP8IMiZFc?= =?us-ascii?Q?IvO0JBhp7qK4IViHTeXFMk+mCkHgw61eTq4STVLTDgcP1PrZMXP8vg+iiR6M?= =?us-ascii?Q?CSx+FnBP1vDaUxt4OpeEZktZNjeMXWhXmL+is5922YqGT3+w5GY2g1ruiY49?= =?us-ascii?Q?QJTWh6skMqrAzHEbX1OY8LUBtfsLw3sFZlyOYvXJdiTPcBWUnsYSU0rObli0?= =?us-ascii?Q?CLGFGGxNx999dPqwoAoMRUU/MLvjgjTXeSCi3U31x+Xl941XgkY2QFRaOw4S?= =?us-ascii?Q?pdvV93mFhwcdnUvYgfoUZpjTxV/mtAVB+KfH7uZD/kUBGiWirGx2IdsB/IuJ?= =?us-ascii?Q?D5fGQo5MFcX7Wlgv3C8nsgNjFlcQcX3dHplPHNv2g8nyWHNtQ75L1NBt7V0g?= =?us-ascii?Q?WwhG9lJDS0HWbd6BjfOSYClkJOfpBmspn/lgpysasWzTyHzM392/LX5Np804?= =?us-ascii?Q?vlCqQf3HPrPW9dfDzz2Z1VXykm0gWGmt7e1pVE+3kTLhg4oFHE3fECF4RZAh?= =?us-ascii?Q?1MIp868bV+ygOpRBw2uM7qyP0d870zFDdp/GRldYBjf4TCijmuJVEGmWSOlA?= =?us-ascii?Q?CMqWOJqjYKf+mvnUI8Un34iWChoX8ItbQdP+TWwiKf6EY5rqx+MyrF2OQn9v?= =?us-ascii?Q?wlI8+c+iB9vjL3cuDhjwkcpZb2evZHUhLNTWfJ0nrFbpwQauddD63bitW7cu?= =?us-ascii?Q?Dtmr7wBVuVqxL4oKeiCJnab7Rt75OfKvVq2xFtdYkNjDFsGRF1S7ayVCa1rE?= =?us-ascii?Q?tqTl8NfH9lm4Oj9BcPNn1poC4WouCVUmClZvHDd/Lkhgzkzut0bijMWnOS+h?= =?us-ascii?Q?sFCMJxdHhIQSe1MTKHbEAzvMZGQ7jJCaapX3ZF37ognVFA+QWLrh3Q6WLN8p?= =?us-ascii?Q?bPRmC0yND9zDLtp7Xz5+VAGkoprBQ0BXHxARgJUBbZWyDoIMmcwQTe34PnCj?= =?us-ascii?Q?/jaanE0STZEtYgxDyFcM9ArrGvGdaixJOFpLQdihTsCxpi4ZAxcvwetU1wG+?= =?us-ascii?Q?VWRlwY6y1BHZEAKM2ojwNrElPQUWxrUlFFOkcCA7sc31reD6a2nlJuSDadvQ?= =?us-ascii?Q?7eejdnH1Luy9HxizcmT9WOGQXj7mEI060tFw4J3kk6JT+NtTHm+OUoYr8Uw/?= =?us-ascii?Q?ri4IPCG/HbQZNrALlumcp9sqYZnBma9oC26vm9krBULlHr5ndzi21cgnvse7?= =?us-ascii?Q?3JNFafe3QYvSGzJynpA42omueaUeZF2x13FG9r2F9a+oZJPn+7PAGeceE3Or?= =?us-ascii?Q?KRVXE3Trtx+X86xXU5vWN6XI?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB4491.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5c0f9d75-32ed-4463-2787-08d8eeb1225a X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2021 10:39:42.4941 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4st6TK2j+d6/RhhC+GsLCkA//iwYo0wmrM+DZPrS2orb9Shkdh77IVsdDlZ/VODFHTNlRVuWuiCTzhLiiseJQ9/4A6bIIcj47hrKmka6oLQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2953 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH 2/3] examples/ipsec-secgw: add UDP encapsulation support X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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 Tejasree, > > > > > > > > Adding lookaside IPsec UDP encapsulation support for NAT > > > > > > > > traversal. > > > > > > > > Added --udp-encap option for application to specify if UDP > > > > > > > > encapsulation need to be enabled. > > > > > > > > Example secgw command with UDP encapsultation enabled: > > > > > > > > -c 0x1 -- -P -p 0x1 --config "(0,0,0)" -f ep0.cfg > > > > > > > > --udp-encap > > > > > > > > > > > > > > Can we have it not as global, but a per SA option? > > > > > > > Add new keyword for SA/SP into ipsec-secgw config file, etc. > > > > > > > Konstantin > > > > > > > > > > > > > > > > > > > Any specific reason to make udp_encap as per SA? > > > > > > UDP encapsulation is a feature which I believe should be > > > > > > application > > > vide. > > > > > > If it supports the feature it should be enabled for all SAs whe= n > > > > > > the UDP > > > port > > > > > > is 4500 which is reserved for it. > > > > > > > > > > Not sure why it has to be application wide? > > > > > Why it is not possible have let say SA1 in ipv4/ipv6 tunnel mode > > > > > over port > > > 0, > > > > > and SA2 with udp encap over port 1? > > > > > Note that in DPDK librte_security it is per SA option. > > > > > > > > UDP encapsulation can be done only if the UDP port is 4500 as per > > > > the > > > specification. > > > > Please correct me if I am wrong. So if UDP port is NOT 4500 and > > > > udp-encap > > > is enabled in the > > > > Command line, UDP encapsulation will not work. > > > > > > I am not asking you so support multiple UDP ports for IPsec encapsula= tion. > > > > Multiple ports are not required to be supported as per specification. > > UDP encapsulation work only on one port i.e. 4500. > > By specification, it says, port 4500 is reserved for NAT traversal and = if a > > Packet has this port, then it has to be processed accordingly. > > > > > What I am saying: it should be possible to use SAs with UDP > > > encapsulation along with SAs without (plain tunnel/transport mode). > > > > Yes it is possible with the current patch. > > If a packet has a UDP port =3D 4500 then it is UDP encapsulated otherwi= se it is > > not. > > Hence, a packet with UDP port other than 4500 will work as it is workin= g > > without --udp-encap param. > > > > > As I understand with your patch it is not possible: if user specified > > > --udp- encap all SAs (on all crypto-devs) will be treated as UDP > > > encapsulated. > > > > Just to correct this statement. > > > > If user specified --udp-encap all SAs (on all crypto-devs) will be trea= ted as > > UDP encapsulated if and only if the UDP port =3D 4500 and not otherwise= . > > > > I hope this statement clears your concern and it makes more sense to ma= ke it > > application vide, just like esn and anti-replay. > > >=20 > [Tejasree] Just realized that all SAs are treated as UDP encapsulated > if the packet type is other than UDP. Will add per SA support. > > Concern with per SA support: we cannot have "udp_encap=3D=3D1" check in t= he prepare_one_packet() > function as SA info is not available at that time and plain UDP packets w= ith port 4500 are > treated as IPsec and results could be unpredictable. =20 If you think global udp_encap would be helpful (let say for prepare_one_pac= ket), I think it is possible to keep it. By default it will be 0, and can be init= ialized to 1, if we have at least one session with udp_encap enabled (after config file = parsing). My thought about it was: -prepare_packet() - mark both ip/esp and ip/udp(sport,dport=3D4500) as ESP = ones, plus set mbuf.packet_type properly (UDP/ESP) (should we set l4_len also?)= .=20 - sad_lookup() - based on packet type (l4_len?) determine location of ESP h= eader and do the lookup. Then if lookup was successful, for UDP packets check d= oes SA.udp_encap=3D=3D1. If no, then drop the packet. =20