HI Ola,
I guess you are looking for standard NIC style IPSEC task
offload?
If yes, should not it be done differently to cover various offload types w.r.t
PKTIO.
1. PKTIO defines the type of offloads available e.g GSO, GRO, TCP, IPSEC
etc
2. The IPSEC decrypted packets can be on any/specific of the
PKTIO/classification queue.
3. In case of IPSEC Session information APIs will only be required.
a. SA information is typically stored in NIC
b. RX – packet will be received as plain text(NIC will do the packet
decryption).
c. TX – packet session information will be passed along with packet
during enqueue.
Regards,
Hemant
From: lng-odp [mailto:[email protected]] On Behalf Of Ola
Liljedahl
Sent: Friday, October 09, 2015 4:53 PM
To: Alexandru Badicioiu <[email protected]>
Cc: LNG ODP Mailman List <[email protected]>
Subject: Re: [lng-odp] [API-NEXT PATCH] api: crypto: add crypto IPSec extension
On 9 October 2015 at 12:48, Alexandru Badicioiu
<[email protected]<mailto:[email protected]>> wrote:
So you would like inline/synchronous API mode to have a completion queue too?
What would be the use for it?
I think we are misunderstanding each other and I haven't been very detailed.
The output of IPsec egress processing must be a queue (e.g. pktio queue) where
complete packets (L2/L3 encapsulation specified by the user) are enqueued. But
there probably also needs to be a queue for sending notifications of errors or
other exceptional events (e.g. SA not found, seqno nears the end etc).
I haven't tried to understand exactly what is needed for inline IPsec on
ingress.
On 9 October 2015 at 13:01, Ola Liljedahl
<[email protected]<mailto:[email protected]>> wrote:
On 9 October 2015 at 10:37, Alexandru Badicioiu
<[email protected]<mailto:[email protected]>> wrote:
This was a long discussion some time ago and the result was that crypto output
should be abstracted in the form of the completion event and access functions
would retrieve status and output packets. Also the implementation is in charge
with crypto completion event allocation and not the application even if this is
not really supported in HW.
Yes that is useful for lookaside crypto/IPsec operations and my intention is
not to change that. But this model is not useful for inline IPsec acceleration.
We need a new or (preferably?) extended API for that. That's what I am asking
about.
I know not all silicon vendors would be able to support inline IPsec
acceleration in HW. But with an Event Machine-like programming model where the
application uses per-queue call-backs, inline IPsec acceleration can be
implemented/emulated in SW. Even if this model is not exposed to the user, an
ODP implementation should be able to do something like it "under the hood".
The previous approach was that application supplied the completion event as
being the output packet but this was regarded as a hack.
Alex
On 9 October 2015 at 11:28, Ola Liljedahl
<[email protected]<mailto:[email protected]>> wrote:
On 9 October 2015 at 09:34, Alexandru Badicioiu
<[email protected]<mailto:[email protected]>> wrote:
The problem you raised is not strictly related to this patch.
A crypto session has an output queue (for async mode) where the results ,
including the operation status, will be delivered. There is nothing in the API
to prevent using a pktio output queue for crypto completion events but the
pktio should be able to process the event as the application would do.
In this case an extension of pktio functionality would be required.
Yes but I was thinking of some change (in API and implementation) where the
output of the crypto operations is the actual packet (with L2/L3
encapsulation), not a crypto completion event.
Alex
On 8 October 2015 at 20:13, Ola Liljedahl
<[email protected]<mailto:[email protected]>> wrote:
Can this proposal be extended to handle inline IPsec processing, e.g. encrypt
and encapsulate packet (include Ethernet framing) and then send to (enqueue) to
some user-defined queue (which might be a pktio output queue)?
Need some way to report errors and other conditions back to SW so might need
some kind of ipsec notification event.
Something for the ingress side as well, e.g. connect user-defined queues to
IPsec input queue(s) and then specify corresponding output queues.
On 31 July 2015 at 11:30, Alexandru Badicioiu
<[email protected]<mailto:[email protected]>> wrote:
On 30 July 2015 at 17:44, Stuart Haslam
<[email protected]<mailto:[email protected]>> wrote:
On Thu, Jul 30, 2015 at 02:42:08PM +0300, Alexandru Badicioiu wrote:
> On 30 July 2015 at 13:50, Stuart Haslam
> <[email protected]<mailto:[email protected]>> wrote:
>
> > On Wed, Jul 22, 2015 at 11:26:03AM +0300,
> > [email protected]<mailto:[email protected]>
> > wrote:
> > > From: Alexandru Badicioiu
> > > <[email protected]<mailto:[email protected]>>
> > >
> > > This patch adds IPSec protocol processing capabilities to crypto
> > > sesssions. Implementations which have these capabilities in hardware
> > > crypto engines can use the extension to offload the application from
> > > IPSec protocol processing.
> > >
> > > Signed-off-by: Alexandru Badicioiu
> > > <[email protected]<mailto:[email protected]>>
> > > ---
> > > include/odp/api/crypto_ipsec.h | 110
> > ++++++++++++++++++++
> > > platform/linux-generic/include/odp/crypto.h | 2 +
> > > .../include/odp/plat/crypto_ipsec_types.h | 53 ++++++++++
> > > 3 files changed, 165 insertions(+), 0 deletions(-)
> > > create mode 100644 include/odp/api/crypto_ipsec.h
> > > create mode 100644
> > platform/linux-generic/include/odp/plat/crypto_ipsec_types.h
> > >
> > > diff --git a/include/odp/api/crypto_ipsec.h
> > b/include/odp/api/crypto_ipsec.h
> > > new file mode 100644
> > > index 0000000..e59fea4
> > > --- /dev/null
> > > +++ b/include/odp/api/crypto_ipsec.h
> > > @@ -0,0 +1,110 @@
> > > +/* Copyright (c) 2014, Linaro Limited
> > > + * All rights reserved.
> > > + *
> > > + * SPDX-License-Identifier: BSD-3-Clause
> > > + */
> > > +
> > > +/**
> > > + * @file
> > > + *
> > > + * ODP crypto IPSec extension
> > > + */
> > > +
> > > +#ifndef ODP_API_CRYPTO_IPSEC_H_
> > > +#define ODP_API_CRYPTO_IPSEC_H_
> > > +
> > > +#ifdef __cplusplus
> > > +extern "C" {
> > > +#endif
> > > +
> > > +/**
> > > + * @enum odp_ipsec_outhdr_type
> > > + * IPSec tunnel outer header type
> > > + *
> > > + * @enum odp_ipsec_ar_ws
> > > + * IPSec Anti-replay window size
> > > + *
> > > + */
> > > +
> > > +typedef struct odp_ipsec_params {
> > > + uint32_t spi; /** SPI value */
> > > + uint32_t seq; /** Initial SEQ number */
> > > + enum odp_ipsec_ar_ws ar_ws; /** Anti-replay window size -
> > > + inbound session with
> > authentication */
> >
> > This name is pretty cryptic, how about just replay_window?
> >
> [Alex] The standard name for this parameter is anti-replay window. In the
> context of IPSec this should not be cryptic (odp_ipsec_arw vs odp_arw). If
> your suggestion is to replace the name of the struct member - ar_ws with
> replay_window I'm fine with it but not the name of the enum
> (odp_ipsec_ar_ws).
> Or maybe change it to enum odp_ipsec_arw.
I meant the variable name, don't mind about the enum name.
[Alex] I'm OK with the change.
> >
> > > + odp_bool_t esn; /** Use extended sequence numbers */
> > > + odp_bool_t auto_iv; /** Auto IV generation for each operation.
> > */
> > > + uint16_t out_hdr_size; /** outer header size - tunnel mode */
> > > + uint8_t *out_hdr; /** outer header - tunnel mode */
> >
> > Can these be 0 and NULL if the application wants tunnel mode but wants
> > to handle the outer header itself? (i.e. add ESP head/tail and include
> > inner IP header in encap data)
> >
> [Alex] Yes, that is the intended usage. If requested mode is tunnel and
> there's no out_hdr specified, the application has to add it.
> > > + enum odp_ipsec_outhdr_type out_hdr_type; /* outer header type -
> > > + tunnel mode */
> > > + odp_bool_t ip_csum; /** update/verify ip header checksum */
> > > + odp_bool_t ip_dttl; /** decrement ttl - tunnel mode encap &
> > decap */
> > > + odp_bool_t remove_outer_hdr; /** remove outer header - tunnel mode
> > decap */
> > > + odp_bool_t copy_dscp; /** DiffServ Copy - Copy the IPv4 TOS or
> > > + IPv6 Traffic Class byte from the
> > inner/outer
> > > + IP header to the outer/inner IP header
> > -
> > > + tunnel mode encap & decap */
> > > + odp_bool_t copy_df; /** Copy DF bit - copy the DF bit from
> > > + the inner IP header to the
> > > + outer IP header - tunnel mode encap */
> > > + odp_bool_t nat_t; /** NAT-T encapsulation enabled - tunnel
> > mode */
> > > + odp_bool_t udp_csum; /** Update/verify UDP csum when NAT-T
> > enabled */
> > > +
> > > +} odp_ipsec_params_t;
> > > +
> > > +/**
> > > + * @enum odp_ipsec_mode:ODP_IPSEC_MODE_TUNNEL
> > > + * IPSec tunnel mode
> > > + *
> > > + * @enum odp_ipsec_mode:ODP_IPSEC_MODE_TRANSPORT
> > > + * IPSec transport mode
> > > + *
> > > + * @enum odp_ipsec_proto
> > > + * IPSec protocol
> > > + */
> > > +
> > > +/**
> > > + * Configure crypto session for IPsec processing
> > > + *
> > > + * Configures a crypto session for IPSec protocol processing.
> > > + * Packets submitted to an IPSec enabled session will have
> > > + * relevant IPSec headers/trailers and tunnel headers
> > > + * added/removed by the crypto implementation.
> > > + * For example, the input packet for an IPSec ESP transport
> > > + * enabled session should be the clear text packet with
> > > + * no ESP headers/trailers prepared in advance for crypto operation.
> > > + * The output packet will have ESP header, IV, trailer and the ESP ICV
> > > + * added by crypto implementation.
> >
> > If a packet fails a check on decap (e.g. out of window), presumably the
> > application gets an odp_crypto_op_result_t with ok=false, but is there
> > any way for it to tell what failed?
> > [Alex] Crypto operation error status should be extended with a code for
> > out of window condition.
> > > + * Depending on the particular capabilities of an implementation and
> > > + * the parameters enabled by application, the application may be
> > > + * partially or completely offloaded from IPSec protocol processing.
> > > + * For example, if an implementation does not support checksum
> > > + * update for IP header after adding ESP header the application
> > > + * should update after crypto IPSec operation.
> > > + *
> > > + * If an implementation does not support a particular set of
> > > + * arguments it should return error.
> > > + *
> > > + * @param session Session handle
> > > + * @param ipsec_mode IPSec protocol mode
> > > + * @param ipsec_proto IPSec protocol
> > > + * @param ipsec_params IPSec parameters. Parameters which are
> > not
> > > + * relevant for selected protocol & mode are
> > ignored -
> > > + * e.g. outer_hdr/size set for ESP transport mode.
> > > + * @retval 0 on success
> > > + * @retval <0 on failure
> > > + */
> > > +int odp_crypto_session_config_ipsec(odp_crypto_session_t session,
> > > + enum odp_ipsec_mode ipsec_mode,
> > > + enum odp_ipsec_proto ipsec_proto,
> > > + odp_ipsec_params_t ipsec_params);
> >
> > Can this be called multiple times on the same session to update the
> > parameters, or would the session need to be destroyed and recreated?
> >
> [Alex] No, this is not the intended use of this function.
> This is to be called on a raw session (algorithm only). To change a crypto
> session additional functions should be used.
>
> >
> > Is it valid to create a session, issue a few operations, then later add
> > the IPsec protocol config for that session?
> >
> [Alex] While this might work for a particular implementation/platform, I'm
> wondering if there's an use case for it?
>
I wasn't thinking about a particular use case, there likely isn't one,
just that how it's currently defined is open to misinterpretation/misuse.
[Alex] As we have only one session create call the session must be usable right
after creation. Being possible to extend the session for protocol processing
after some traffic passed it's up to implementation - platform guys may give
some inputs here. Other question can be - can we configure a session for
protocol processing while traffic is passing? Again it may be possible for some
and not for others. If there's no use-case for it then applications should not
rely on this and config can return an error.
Alternatively, we may need enable/disable calls for crypto sessions, similarly
with pktio start/stop functions. Pktio start/stop functions are meant to
clearly mark configuration phase - e.g. open pktio, config classification,
start pktio. However, enable/disable calls could be required by IPSec rekeying
process.
> >
> > I'm wondering why the params here weren't just made an extension of the
> > odp_crypto_session_params_t in the initial session create.
> >
> [Alex] Do you mean to add these parameters as members of
> odp_crypto_session_params_t or to extend session_create call to take IPSec
> params?
The first.
> It wouldn't be a good idea to embed the IPSec parameters into the
> odp_crypto_session_params_t as IPSec is just a protocol among others
> supported by crypto engines (SSL/TLS, MACSEC, SRTP, etc).
It could be done with a union + enum for each protocol (or NONE) and if
we add odp_crypto_session_params_init(), which we should have anyway,
you wouldn't need to know those fields existed when creating non-protocol
sessions.
[Alex] I still don't think is a good idea. An application using only raw
sessions will waste memory with fields it actually doesn't use. Making a
structure larger is not cache/performance friendly, software running on the
cores access these structures on a per-packet basis. Crypto sessions can be
potentially millions.
> I think having a separate call odp_crypto_session_config_ipsec() makes the
> source code more readable regarding the intent of the application rather
> than filling in lots of IPSec parameters and calling then session_create().
>
If there's only one way of doing it right - protocol config/params are
set at session create time and not modified - and a number of ways of
getting it wrong then it makes sense to define the API such that it can
only be done the right way.
[Alex] I'm not sure it is possible to design an API __impossible__ to misuse -
i.e. not possible to compile a program which misuses the API. I think that
misuse rather should fail gracefully and with no side effects. There are other
ODP API areas that can be easily misused - for example pktio - can we remove
the default input queue after start function or while traffic is passing ? Can
we remove the queue after sending a few packets but without stopping?
Scheduling API requires calling pause before exiting a schedule loop - what
happens if pause is not called?
I think these are rather runtime aspects that should be handled at runtime.
More than that, different platforms/implementation may behave differently, but
a portable application should not be based on a particular behavior.
--
Stuart.
_______________________________________________
lng-odp mailing list
[email protected]<mailto:[email protected]>
https://lists.linaro.org/mailman/listinfo/lng-odp
_______________________________________________
lng-odp mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/lng-odp
