Re: [dpdk-dev] [PATCH 2/3] examples/ipsec-secgw: add UDP encapsulation support

[Tejasree Kondoj <ktejasree@marvell.com>]

Hi Konstantin,

Please see inline.

Thanks
Tejasree

> -----Original Message-----
> From: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Sent: Wednesday, March 24, 2021 4:10 PM
> 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
> Subject: [EXT] RE: [dpdk-dev] [PATCH 2/3] examples/ipsec-secgw: add UDP
> encapsulation support
> 
> External Email
> 
> ----------------------------------------------------------------------
> 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.
> 
> 
> 
> 
[Tejasree] l4_len setting is not needed. mbuf.packet_type can be used.
Will send v2 with per SA support.