DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Tejasree Kondoj <ktejasree@marvell.com>,
	Akhil Goyal <gakhil@marvell.com>,
	 "Nicolau, Radu" <radu.nicolau@intel.com>
Cc: Anoob Joseph <anoobj@marvell.com>,
	Ankur Dwivedi <adwivedi@marvell.com>,
	Jerin Jacob Kollanukkaran <jerinj@marvell.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 2/3] examples/ipsec-secgw: add UDP encapsulation support
Date: Wed, 24 Mar 2021 10:39:42 +0000
Message-ID: <DM6PR11MB4491413A434DFECC5B3139DC9A639@DM6PR11MB4491.namprd11.prod.outlook.com> (raw)
In-Reply-To: <PH0PR18MB3864F350480FF14698C16453A8639@PH0PR18MB3864.namprd18.prod.outlook.com>

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:
> > > > > > > > <secgw> -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 when
> > > > > > 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 encapsulation.
> >
> > 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 = 4500 then it is UDP encapsulated otherwise it is
> > not.
> > Hence, a packet with UDP port other than 4500 will work as it is working
> > 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 treated as
> > UDP encapsulated if and only if the UDP port = 4500 and not otherwise.
> >
> > I hope this statement clears your concern and it makes more sense to make it
> > application vide, just like esn and anti-replay.
> >
> 
> [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==1" check in the prepare_one_packet()
> function as SA info is not available at that time and plain UDP packets with port 4500 are
> treated as IPsec and results could be unpredictable.
 
If you think global udp_encap would be helpful (let say for prepare_one_packet),
I think it is possible to keep it. By default it will be 0, and can be initialized 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=4500) as ESP ones,
  plus set mbuf.packet_type properly (UDP/ESP) (should we set l4_len also?). 
- sad_lookup() - based on packet type (l4_len?) determine location of ESP header
  and do the lookup. Then if lookup was successful, for UDP packets check does
  SA.udp_encap==1. If no, then drop the packet.

 




  reply	other threads:[~2021-03-24 10:39 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-15 10:36 [dpdk-dev] [PATCH 0/3] add lookaside IPsec UDP encapsulation and transport mode Tejasree Kondoj
2021-03-15 10:36 ` [dpdk-dev] [PATCH 1/3] crypto/octeontx2: add UDP encapsulation support Tejasree Kondoj
2021-03-15 10:36 ` [dpdk-dev] [PATCH 2/3] examples/ipsec-secgw: " Tejasree Kondoj
2021-03-19 16:46   ` Ananyev, Konstantin
2021-03-23  8:02     ` Akhil Goyal
2021-03-23 14:29       ` Ananyev, Konstantin
2021-03-23 15:06         ` Akhil Goyal
2021-03-23 15:46           ` Ananyev, Konstantin
2021-03-23 17:54             ` Akhil Goyal
2021-03-24  9:45               ` Tejasree Kondoj
2021-03-24 10:39                 ` Ananyev, Konstantin [this message]
2021-03-25  8:38                   ` Tejasree Kondoj
2021-03-15 10:36 ` [dpdk-dev] [PATCH 3/3] crypto/octeontx2: support lookaside IPv4 transport mode Tejasree Kondoj

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=DM6PR11MB4491413A434DFECC5B3139DC9A639@DM6PR11MB4491.namprd11.prod.outlook.com \
    --to=konstantin.ananyev@intel.com \
    --cc=adwivedi@marvell.com \
    --cc=anoobj@marvell.com \
    --cc=dev@dpdk.org \
    --cc=gakhil@marvell.com \
    --cc=jerinj@marvell.com \
    --cc=ktejasree@marvell.com \
    --cc=radu.nicolau@intel.com \
    /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

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git