patches for DPDK stable branches
 help / color / mirror / Atom feed
From: Kevin Traynor <ktraynor@redhat.com>
To: Mariusz Drost <mariuszx.drost@intel.com>,
	radu.nicolau@intel.com, akhil.goyal@nxp.com,
	konstantin.ananyev@intel.com
Cc: stable@dpdk.org
Subject: Re: [dpdk-stable] [PATCH 18.11] examples/ipsec-secgw: fix inline modes
Date: Tue, 10 Sep 2019 11:19:03 +0100	[thread overview]
Message-ID: <38d128d1-b6d8-cc06-9fd6-6516200b1705@redhat.com> (raw)
In-Reply-To: <20190910093240.16448-1-mariuszx.drost@intel.com>

On 10/09/2019 10:32, Mariusz Drost wrote:
> [ upstream commit b1a3ac782d6020e6877e97a067613bbb2b8564b1 ]
> 
> Application ipsec-secgw is not working for IPv4 transport mode and for
> IPv6 both transport and tunnel mode.
> 
> IPv6 tunnel mode is not working due to wrongly assigned fields of
> security association patterns, as it was IPv4, during creation of
> inline crypto session.
> 
> IPv6 and IPv4 transport mode is iterating through security capabilities
> until it reaches tunnel, which causes session to be created as tunnel,
> instead of transport. Another issue, is that config file does not
> provide source and destination ip addresses for transport mode, which
> are required by NIC to perform inline crypto. It uses default addresses
> stored in security association (all zeroes), which causes dropped
> packages.
> 
> To fix that, reorganization of code in create_session() is needed,
> to behave appropriately to given protocol (IPv6/IPv4). Change in
> iteration through security capabilities is also required, to check
> for expected mode (not only tunnel).
> 
> For lack of addresses issue, some resolving mechanism is needed.
> Approach is to store addresses in security association, as it is
> for tunnel mode. Difference is that they are obtained from sp rules,
> instead of config file. To do that, sp[4/6]_spi_present() function
> is used to find addresses based on spi value, and then stored in
> corresponding sa rule. This approach assumes, that every sp rule
> for inline crypto have valid addresses, as well as range of addresses
> is not supported.
> 
> New flags for ipsec_sa structure are required to distinguish between
> IPv4 and IPv6 transport modes. Because of that, there is need to
> change all checks done on these flags, so they work as expected.
> 
> Fixes: ec17993a145a ("examples/ipsec-secgw: support security offload")
> Fixes: 9a0752f498d2 ("net/ixgbe: enable inline IPsec")
> 
> Signed-off-by: Mariusz Drost <mariuszx.drost@intel.com>
> ---

Thanks, added to the queued commits.

  reply	other threads:[~2019-09-10 10:19 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-10  9:32 Mariusz Drost
2019-09-10 10:19 ` Kevin Traynor [this message]
2019-09-10 10:32 ` Ananyev, Konstantin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=38d128d1-b6d8-cc06-9fd6-6516200b1705@redhat.com \
    --to=ktraynor@redhat.com \
    --cc=akhil.goyal@nxp.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=mariuszx.drost@intel.com \
    --cc=radu.nicolau@intel.com \
    --cc=stable@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).