Re: [lng-odp] [API-NEXT PATCH v2 2/3] api: ipsec: add inline IPSEC support

[Bala Manoharan]

On 23 March 2017 at 21:10, Peltonen, Janne (Nokia - FI/Espoo)
<janne.pelto...@nokia.com> wrote:
>> > This is part of odp_ipsec_sa_param_t, so lookup config is per SA.
>>
>> Does that mean that both SPI lookup and DEST ADDR lookup are mandatory?
>> Is there a reason lookup mode is per SA?
>
> The lookup mode is per SA to make it possible to have SAs for which
> not ODP but the application performs the lookup (e.g. currently for
> multicast IPsec SAs that do not have unique SPIs and require src
> address lookup too, or for any other SAs with weird lookup rules)
> and uses look-a-side IPsec ops with an explicit SA to do the
> IPsec transforms.
>
> Thus, I think at minimum the ODP_IPSEC_LOOKUP_DISABLED needs to
> be per-SA even if the SPI versus SPI+dstaddr selection would be
> global.

If I understand your requirement correctly then we could add a boolean
"enable_lookup" per SA which when disabled will
remove the SA from any lookup and we can configure the lookup mode as
a global configuration.

Regards,
Bala

>
> Janne
>
>
>> -Original Message-
>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Bala 
>> Manoharan
>> Sent: Thursday, March 23, 2017 4:42 PM
>> To: Savolainen, Petri (Nokia - FI/Espoo) 
>> <petri.savolai...@nokia-bell-labs.com>
>> Cc: lng-odp-forward <lng-odp@lists.linaro.org>
>> Subject: Re: [lng-odp] [API-NEXT PATCH v2 2/3] api: ipsec: add inline IPSEC 
>> support
>>
>> Regards,
>> Bala
>>
>>
>> On 23 March 2017 at 17:40, Savolainen, Petri (Nokia - FI/Espoo)
>> <petri.savolai...@nokia-bell-labs.com> wrote:
>> >> >
>> >> >  /**
>> >> > @@ -381,11 +547,29 @@ typedef enum odp_ipsec_lookup_mode_t {
>> >> > ODP_IPSEC_LOOKUP_DISABLED = 0,
>> >> >
>> >> > /** Inbound SA lookup is enabled. Used SPI values must be
>> >> unique. */
>> >> > -   ODP_IPSEC_LOOKUP_IN_UNIQUE_SA
>> >> > +   ODP_IPSEC_LOOKUP_IN_UNIQUE_SPI,
>> >> > +
>> >> > +   /** Inbound SA lookup is enabled. Lookup matches both SPI and
>> >> > + * destination IP address. Used SPI values must be unique. */
>> >> > +   ODP_IPSEC_LOOKUP_IN_DSTADDR_UNIQUE_SPI
>> >> >
>> >> >  } odp_ipsec_lookup_mode_t;
>> >>
>> >> odp_ipsec_lookup_mode_t is not added either in odp_ipsec_config() or
>> >> in odp_ipsec_capability().
>> >> I believe this should be added in both these struct?
>> >
>> >
>> > This is part of odp_ipsec_sa_param_t, so lookup config is per SA.
>>
>> Does that mean that both SPI lookup and DEST ADDR lookup are mandatory?
>> Is there a reason lookup mode is per SA?
>>
>> >
>> >
>> >>
>> >> >
>> >> >
>> >> >  /**
>> >> > + * Result event destination
>> >> > + */
>> >> > +typedef enum odp_ipsec_dest_mode_t {
>> >> > +   /** Destination for IPSEC result events is a queue. */
>> >> > +   ODP_IPSEC_DEST_QUEUE = 0,
>> >> > +
>> >> > +   /** Destination for IPSEC result events is the classifier.
>> >> > +*  IPSEC capability 'cls_inline' determines if inline
>> >> classification
>> >> > +*  is supported. */
>> >> > +   ODP_IPSEC_DEST_CLS
>> >> > +
>> >> > +} odp_ipsec_dest_mode_t;
>> >>
>> >> Should'nt we add a dest_mode ODP_IPSEC_DEST_PKTIO for outbound inline
>> >> when the packet is sent out through interface directly.
>> >
>> > This selection is for result events. For output direction, queue are the 
>> > only option
>> (for events). Queue vs inline pktout is selected by odp_ipsec_out_enq() vs
>> odp_ipsec_out_inline(). Selection of output pktio (or TM queue in the 
>> future) is
>> parameters to odp_ipsec_out_inline().
>>
>> Yes. But the odp_ipsec_dest_mode_t is available in SA params and if
>> the SA is configured in outbound direction and linked to the pktio
>> then the configuration of dest_mode cannot be ODP_IPSEC_DEST_QUEUE.
>>
>> >
>> > -Petri
>> >
>> >
>> >

Re: [lng-odp] [API-NEXT PATCH v2 2/3] api: ipsec: add inline IPSEC support

[Peltonen, Janne (Nokia - FI/Espoo)]

> > This is part of odp_ipsec_sa_param_t, so lookup config is per SA.
> 
> Does that mean that both SPI lookup and DEST ADDR lookup are mandatory?
> Is there a reason lookup mode is per SA?

The lookup mode is per SA to make it possible to have SAs for which
not ODP but the application performs the lookup (e.g. currently for
multicast IPsec SAs that do not have unique SPIs and require src
address lookup too, or for any other SAs with weird lookup rules)
and uses look-a-side IPsec ops with an explicit SA to do the
IPsec transforms.

Thus, I think at minimum the ODP_IPSEC_LOOKUP_DISABLED needs to
be per-SA even if the SPI versus SPI+dstaddr selection would be
global.

Janne


> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Bala 
> Manoharan
> Sent: Thursday, March 23, 2017 4:42 PM
> To: Savolainen, Petri (Nokia - FI/Espoo) 
> <petri.savolai...@nokia-bell-labs.com>
> Cc: lng-odp-forward <lng-odp@lists.linaro.org>
> Subject: Re: [lng-odp] [API-NEXT PATCH v2 2/3] api: ipsec: add inline IPSEC 
> support
> 
> Regards,
> Bala
> 
> 
> On 23 March 2017 at 17:40, Savolainen, Petri (Nokia - FI/Espoo)
> <petri.savolai...@nokia-bell-labs.com> wrote:
> >> >
> >> >  /**
> >> > @@ -381,11 +547,29 @@ typedef enum odp_ipsec_lookup_mode_t {
> >> > ODP_IPSEC_LOOKUP_DISABLED = 0,
> >> >
> >> > /** Inbound SA lookup is enabled. Used SPI values must be
> >> unique. */
> >> > -   ODP_IPSEC_LOOKUP_IN_UNIQUE_SA
> >> > +   ODP_IPSEC_LOOKUP_IN_UNIQUE_SPI,
> >> > +
> >> > +   /** Inbound SA lookup is enabled. Lookup matches both SPI and
> >> > + * destination IP address. Used SPI values must be unique. */
> >> > +   ODP_IPSEC_LOOKUP_IN_DSTADDR_UNIQUE_SPI
> >> >
> >> >  } odp_ipsec_lookup_mode_t;
> >>
> >> odp_ipsec_lookup_mode_t is not added either in odp_ipsec_config() or
> >> in odp_ipsec_capability().
> >> I believe this should be added in both these struct?
> >
> >
> > This is part of odp_ipsec_sa_param_t, so lookup config is per SA.
> 
> Does that mean that both SPI lookup and DEST ADDR lookup are mandatory?
> Is there a reason lookup mode is per SA?
> 
> >
> >
> >>
> >> >
> >> >
> >> >  /**
> >> > + * Result event destination
> >> > + */
> >> > +typedef enum odp_ipsec_dest_mode_t {
> >> > +   /** Destination for IPSEC result events is a queue. */
> >> > +   ODP_IPSEC_DEST_QUEUE = 0,
> >> > +
> >> > +   /** Destination for IPSEC result events is the classifier.
> >> > +*  IPSEC capability 'cls_inline' determines if inline
> >> classification
> >> > +*  is supported. */
> >> > +   ODP_IPSEC_DEST_CLS
> >> > +
> >> > +} odp_ipsec_dest_mode_t;
> >>
> >> Should'nt we add a dest_mode ODP_IPSEC_DEST_PKTIO for outbound inline
> >> when the packet is sent out through interface directly.
> >
> > This selection is for result events. For output direction, queue are the 
> > only option
> (for events). Queue vs inline pktout is selected by odp_ipsec_out_enq() vs
> odp_ipsec_out_inline(). Selection of output pktio (or TM queue in the future) 
> is
> parameters to odp_ipsec_out_inline().
> 
> Yes. But the odp_ipsec_dest_mode_t is available in SA params and if
> the SA is configured in outbound direction and linked to the pktio
> then the configuration of dest_mode cannot be ODP_IPSEC_DEST_QUEUE.
> 
> >
> > -Petri
> >
> >
> >

Re: [lng-odp] [API-NEXT PATCH v2 2/3] api: ipsec: add inline IPSEC support

[Peltonen, Janne (Nokia - FI/Espoo)]

Hi,

A few quick comments below. Petri will probably comment the other points.

Janne

> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Nikhil 
> Agarwal
> Sent: Thursday, March 23, 2017 2:02 PM
> To: Petri Savolainen <petri.savolai...@linaro.org>; lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] [API-NEXT PATCH v2 2/3] api: ipsec: add inline IPSEC 
> support
> 
> Few initial comments:
> 
> - For Mixing inline and async processing must maintain same SA context in HW 
> and
> implementation. In that case, we should shift to async SA creation so that 
> while creating
> an SA, HWinterface can return the context to sw and Async processing can 
> be done for
> that context.
> - Why we want to add different level of header retention, we can add retain 
> header or
> discard.
> - Why parsing is optional and layer wise. Parsing should be same as on the 
> pktio
> interface. Even in the lookaside APIs L3 parsing was mandatory. Otherwise 
> application will
> have to do the parsing on its own. Moreover, application will never know L3 
> protocol if
> there are no parse results.
> - In case outer headers are retained in the packet, hardware will parse 
> packet based outer
> headers not inner. Same goes for classification.

Outer headers are not provided _in the packet_. The retained outer headers are 
not
part of the packet data but stored with the packet in some implementation 
defined
way.

Therefore parsing and classification is done based on the inner headers (or 
rather,
the packet as it appears after IPsec decapsulation).

> - Checksum configuration (For inbound as well as outbound) can be per flow 
> basis, as
> requirement can be different for different flows.

It depends on the definition of flow here. Both locally generated and forwarded 
traffic
may be sent out through the same outbound SA. For forwarded traffic L4 
checksums should
not be (re)generated but for locally originated traffic they should. Also, some 
UDP
protocols like VxLAN do not use checksum.

So, I think checksum generation should be selectable per packet. This is not 
part
of the latest IPsec patch since it probably needs to be done in the generic
packet API. In fact, packet_io.h currently says: "Application may use a packet
metadata flag to disable checksum insertion per packet bases." Such feature is
just missing.

> - Support for ESP/AH and Tunnel/Transport mode should be exposed via 
> capability.
> - Inline SA lookup should also support 3 tuple lookups (SIP, DIP, SPI).

Now lookups that would need source IP would need to be done by the application
in SW. Support in the inline IPsec API can be added later, but I am not sure
if it is needed there right away (it would only be needed for multicast IPsec
traffic anyway, right?).

Right now the API assumes that inbound SAs have unique SPIs, which can make
things easier to implementations. With source address matching in addition
to destination address and SPI you would presumably have non-unique SPIs too.

> - Why there are separate lookup prams in SA, when SA tunnel params already 
> include SIP and
> DIP?

Transport mode SAs do not have the IP addresses.

> - What about enabling HASH distribution post IPSEC for FAT tunnel use case.
> - In per SA params, if dest_mode is ODP_IPSEC_DEST_CLS, why output is to a 
> new CoS, why
> not to default CoS of that pktio. Are we saying that we will have two level of
> classification on that oktio, one before IPsec and one after that?

One reason is that separate CoS allows one to distinguish IPsec
processed packets from other packets in the classification rules.

> - Who holds the responsibility of freeing the l2hdr in 
> odp_ipsec_inline_op_param_t post
> transmission? IUs it mandated to be inside the packet? The why not just use 
> l2_offset?

The implementation copies the l2 header data to its internal storage during
the enqueue call. ODP implementation will not dereference the provided pointer
after the enqueue call returns, so the application is then free to do anything
with it. 
 
> 
> Regards
> Nikhil
> 
> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Petri 
> Savolainen
> Sent: Tuesday, March 21, 2017 7:47 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [API-NEXT PATCH v2 2/3] api: ipsec: add inline IPSEC 
> support
> 
> Added support for inline IPSEC processing on packet input and output. Inline 
> mode IPSEC
> and traffic manager cannot be enabled
> (currently) on the same pktio interface.
> 
> Signed-off-by: Petri Savolainen <petri.savolai...@linaro.org>
> ---
>  include/odp/api/spec/ipsec.h | 348 
> ---
>  include/odp/api/spec/packet_io.h |  32 +++

Re: [lng-odp] [API-NEXT PATCH v2 2/3] api: ipsec: add inline IPSEC support

[Bala Manoharan]

Regards,
Bala


On 23 March 2017 at 17:40, Savolainen, Petri (Nokia - FI/Espoo)
 wrote:
>> >
>> >  /**
>> > @@ -381,11 +547,29 @@ typedef enum odp_ipsec_lookup_mode_t {
>> > ODP_IPSEC_LOOKUP_DISABLED = 0,
>> >
>> > /** Inbound SA lookup is enabled. Used SPI values must be
>> unique. */
>> > -   ODP_IPSEC_LOOKUP_IN_UNIQUE_SA
>> > +   ODP_IPSEC_LOOKUP_IN_UNIQUE_SPI,
>> > +
>> > +   /** Inbound SA lookup is enabled. Lookup matches both SPI and
>> > + * destination IP address. Used SPI values must be unique. */
>> > +   ODP_IPSEC_LOOKUP_IN_DSTADDR_UNIQUE_SPI
>> >
>> >  } odp_ipsec_lookup_mode_t;
>>
>> odp_ipsec_lookup_mode_t is not added either in odp_ipsec_config() or
>> in odp_ipsec_capability().
>> I believe this should be added in both these struct?
>
>
> This is part of odp_ipsec_sa_param_t, so lookup config is per SA.

Does that mean that both SPI lookup and DEST ADDR lookup are mandatory?
Is there a reason lookup mode is per SA?

>
>
>>
>> >
>> >
>> >  /**
>> > + * Result event destination
>> > + */
>> > +typedef enum odp_ipsec_dest_mode_t {
>> > +   /** Destination for IPSEC result events is a queue. */
>> > +   ODP_IPSEC_DEST_QUEUE = 0,
>> > +
>> > +   /** Destination for IPSEC result events is the classifier.
>> > +*  IPSEC capability 'cls_inline' determines if inline
>> classification
>> > +*  is supported. */
>> > +   ODP_IPSEC_DEST_CLS
>> > +
>> > +} odp_ipsec_dest_mode_t;
>>
>> Should'nt we add a dest_mode ODP_IPSEC_DEST_PKTIO for outbound inline
>> when the packet is sent out through interface directly.
>
> This selection is for result events. For output direction, queue are the only 
> option (for events). Queue vs inline pktout is selected by 
> odp_ipsec_out_enq() vs odp_ipsec_out_inline(). Selection of output pktio (or 
> TM queue in the future) is parameters to odp_ipsec_out_inline().

Yes. But the odp_ipsec_dest_mode_t is available in SA params and if
the SA is configured in outbound direction and linked to the pktio
then the configuration of dest_mode cannot be ODP_IPSEC_DEST_QUEUE.

>
> -Petri
>
>
>

Re: [lng-odp] [API-NEXT PATCH v2 2/3] api: ipsec: add inline IPSEC support

[Bala Manoharan]

Regards,
Bala


On 23 March 2017 at 17:32, Nikhil Agarwal  wrote:
> Few initial comments:
>
> - For Mixing inline and async processing must maintain same SA context in HW 
> and implementation. In that case, we should shift to async SA creation so 
> that while creating an SA, HWinterface can return the context to sw and 
> Async processing can be done for that context.
> - Why we want to add different level of header retention, we can add retain 
> header or discard.
> - Why parsing is optional and layer wise. Parsing should be same as on the 
> pktio interface. Even in the lookaside APIs L3 parsing was mandatory. 
> Otherwise application will have to do the parsing on its own. Moreover, 
> application will never know L3 protocol if there are no parse results.
> - In case outer headers are retained in the packet, hardware will parse 
> packet based outer headers not inner. Same goes for classification.
> - Checksum configuration (For inbound as well as outbound) can be per flow 
> basis, as requirement can be different for different flows.
> - Support for ESP/AH and Tunnel/Transport mode should be exposed via 
> capability.
> - Inline SA lookup should also support 3 tuple lookups (SIP, DIP, SPI).
> - Why there are separate lookup prams in SA, when SA tunnel params already 
> include SIP and DIP?
> - What about enabling HASH distribution post IPSEC for FAT tunnel use case.
> - In per SA params, if dest_mode is ODP_IPSEC_DEST_CLS, why output is to a 
> new CoS, why not to default CoS of that pktio. Are we saying that we will 
> have two level of classification on that oktio, one before IPsec and one 
> after that?

I am not sure if using the same default CoS of pktio would be
feasible, since it is possible that the default CoS could have L2 PMR
rules and the output packet is an IP packet. Do you have an issue in
implementing with a different CoS?

> - Who holds the responsibility of freeing the l2hdr in 
> odp_ipsec_inline_op_param_t post transmission? IUs it mandated to be inside 
> the packet? The why not just use l2_offset?
>
> Regards
> Nikhil
>
> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Petri 
> Savolainen
> Sent: Tuesday, March 21, 2017 7:47 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [API-NEXT PATCH v2 2/3] api: ipsec: add inline IPSEC 
> support
>
> Added support for inline IPSEC processing on packet input and output. Inline 
> mode IPSEC and traffic manager cannot be enabled
> (currently) on the same pktio interface.
>
> Signed-off-by: Petri Savolainen 
> ---
>  include/odp/api/spec/ipsec.h | 348 
> ---
>  include/odp/api/spec/packet_io.h |  32 
>  2 files changed, 355 insertions(+), 25 deletions(-)
>
> diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h 
> index e951e49..23d02cf 100644
> --- a/include/odp/api/spec/ipsec.h
> +++ b/include/odp/api/spec/ipsec.h
> @@ -19,6 +19,8 @@ extern "C" {
>  #endif
>
>  #include 
> +#include 
> +#include 
>
>  /** @defgroup odp_ipsec ODP IPSEC
>   *  Operations of IPSEC API.
> @@ -51,11 +53,43 @@ typedef enum odp_ipsec_op_mode_t {
>   * Application uses asynchronous IPSEC operations,
>   * which return results via events.
>   */
> -   ODP_IPSEC_OP_MODE_ASYNC
> +   ODP_IPSEC_OP_MODE_ASYNC,
> +
> +   /** Inline IPSEC operation
> + *
> + * Packet input/output is connected directly to IPSEC 
> inbound/outbound
> + * processing. Application uses asynchronous or inline IPSEC
> + * operations.
> + */
> +   ODP_IPSEC_OP_MODE_INLINE,
> +
> +   /** IPSEC is disabled in inbound / outbound direction */
> +   ODP_IPSEC_OP_MODE_DISABLED
>
>  } odp_ipsec_op_mode_t;
>
>  /**
> + * Protocol layers in IPSEC configuration  */ typedef enum
> +odp_ipsec_proto_layer_t {
> +   /** No layers */
> +   ODP_IPSEC_LAYER_NONE = 0,
> +
> +   /** Layer L2 protocols (Ethernet, VLAN, etc) */
> +   ODP_IPSEC_LAYER_L2,
> +
> +   /** Layer L3 protocols (IPv4, IPv6, ICMP, IPSec, etc) */
> +   ODP_IPSEC_LAYER_L3,
> +
> +   /** Layer L4 protocols (UDP, TCP, SCTP) */
> +   ODP_IPSEC_LAYER_L4,
> +
> +   /** All layers */
> +   ODP_IPSEC_LAYER_ALL
> +
> +} odp_ipsec_proto_layer_t;
> +
> +/**
>   * Configuration options for IPSEC inbound processing
>   */
>  typedef struct odp_ipsec_inbound_config_t { @@ -77,9 +111,113 @@ typedef 
> struct odp_ipsec_inbound_config_t {
> uint32_t max;
> } spi;
>
> +   /** Retain outer headers
> +*
> +*  Select up to which protocol layer (at least) outer headers are
> +*  retained in inbound inline processing. Default value is
> +*  ODP_IPSEC_LAYER_NONE.
> +*
> +*  ODP_IPSEC_LAYER_NONE: Application does not require any outer
> +*headers to be retained.
> 

Re: [lng-odp] [API-NEXT PATCH v2 2/3] api: ipsec: add inline IPSEC support

[Savolainen, Petri (Nokia - FI/Espoo)]

> >
> >  /**
> > @@ -381,11 +547,29 @@ typedef enum odp_ipsec_lookup_mode_t {
> > ODP_IPSEC_LOOKUP_DISABLED = 0,
> >
> > /** Inbound SA lookup is enabled. Used SPI values must be
> unique. */
> > -   ODP_IPSEC_LOOKUP_IN_UNIQUE_SA
> > +   ODP_IPSEC_LOOKUP_IN_UNIQUE_SPI,
> > +
> > +   /** Inbound SA lookup is enabled. Lookup matches both SPI and
> > + * destination IP address. Used SPI values must be unique. */
> > +   ODP_IPSEC_LOOKUP_IN_DSTADDR_UNIQUE_SPI
> >
> >  } odp_ipsec_lookup_mode_t;
> 
> odp_ipsec_lookup_mode_t is not added either in odp_ipsec_config() or
> in odp_ipsec_capability().
> I believe this should be added in both these struct?


This is part of odp_ipsec_sa_param_t, so lookup config is per SA.


> 
> >
> >
> >  /**
> > + * Result event destination
> > + */
> > +typedef enum odp_ipsec_dest_mode_t {
> > +   /** Destination for IPSEC result events is a queue. */
> > +   ODP_IPSEC_DEST_QUEUE = 0,
> > +
> > +   /** Destination for IPSEC result events is the classifier.
> > +*  IPSEC capability 'cls_inline' determines if inline
> classification
> > +*  is supported. */
> > +   ODP_IPSEC_DEST_CLS
> > +
> > +} odp_ipsec_dest_mode_t;
> 
> Should'nt we add a dest_mode ODP_IPSEC_DEST_PKTIO for outbound inline
> when the packet is sent out through interface directly.

This selection is for result events. For output direction, queue are the only 
option (for events). Queue vs inline pktout is selected by odp_ipsec_out_enq() 
vs odp_ipsec_out_inline(). Selection of output pktio (or TM queue in the 
future) is parameters to odp_ipsec_out_inline().

-Petri

Re: [lng-odp] [API-NEXT PATCH v2 2/3] api: ipsec: add inline IPSEC support

[Nikhil Agarwal]

Few initial comments:

- For Mixing inline and async processing must maintain same SA context in HW 
and implementation. In that case, we should shift to async SA creation so that 
while creating an SA, HWinterface can return the context to sw and Async 
processing can be done for that context.
- Why we want to add different level of header retention, we can add retain 
header or discard.
- Why parsing is optional and layer wise. Parsing should be same as on the 
pktio interface. Even in the lookaside APIs L3 parsing was mandatory. Otherwise 
application will have to do the parsing on its own. Moreover, application will 
never know L3 protocol if there are no parse results.
- In case outer headers are retained in the packet, hardware will parse packet 
based outer headers not inner. Same goes for classification.
- Checksum configuration (For inbound as well as outbound) can be per flow 
basis, as requirement can be different for different flows.
- Support for ESP/AH and Tunnel/Transport mode should be exposed via capability.
- Inline SA lookup should also support 3 tuple lookups (SIP, DIP, SPI).
- Why there are separate lookup prams in SA, when SA tunnel params already 
include SIP and DIP?
- What about enabling HASH distribution post IPSEC for FAT tunnel use case.
- In per SA params, if dest_mode is ODP_IPSEC_DEST_CLS, why output is to a new 
CoS, why not to default CoS of that pktio. Are we saying that we will have two 
level of classification on that oktio, one before IPsec and one after that?
- Who holds the responsibility of freeing the l2hdr in 
odp_ipsec_inline_op_param_t post transmission? IUs it mandated to be inside the 
packet? The why not just use l2_offset?

Regards
Nikhil

-Original Message-
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Petri 
Savolainen
Sent: Tuesday, March 21, 2017 7:47 PM
To: lng-odp@lists.linaro.org
Subject: [lng-odp] [API-NEXT PATCH v2 2/3] api: ipsec: add inline IPSEC support

Added support for inline IPSEC processing on packet input and output. Inline 
mode IPSEC and traffic manager cannot be enabled
(currently) on the same pktio interface.

Signed-off-by: Petri Savolainen 
---
 include/odp/api/spec/ipsec.h | 348 ---
 include/odp/api/spec/packet_io.h |  32 
 2 files changed, 355 insertions(+), 25 deletions(-)

diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h index 
e951e49..23d02cf 100644
--- a/include/odp/api/spec/ipsec.h
+++ b/include/odp/api/spec/ipsec.h
@@ -19,6 +19,8 @@ extern "C" {
 #endif
 
 #include 
+#include 
+#include 
 
 /** @defgroup odp_ipsec ODP IPSEC
  *  Operations of IPSEC API.
@@ -51,11 +53,43 @@ typedef enum odp_ipsec_op_mode_t {
  * Application uses asynchronous IPSEC operations,
  * which return results via events.
  */
-   ODP_IPSEC_OP_MODE_ASYNC
+   ODP_IPSEC_OP_MODE_ASYNC,
+
+   /** Inline IPSEC operation
+ *
+ * Packet input/output is connected directly to IPSEC inbound/outbound
+ * processing. Application uses asynchronous or inline IPSEC
+ * operations.
+ */
+   ODP_IPSEC_OP_MODE_INLINE,
+
+   /** IPSEC is disabled in inbound / outbound direction */
+   ODP_IPSEC_OP_MODE_DISABLED
 
 } odp_ipsec_op_mode_t;
 
 /**
+ * Protocol layers in IPSEC configuration  */ typedef enum 
+odp_ipsec_proto_layer_t {
+   /** No layers */
+   ODP_IPSEC_LAYER_NONE = 0,
+
+   /** Layer L2 protocols (Ethernet, VLAN, etc) */
+   ODP_IPSEC_LAYER_L2,
+
+   /** Layer L3 protocols (IPv4, IPv6, ICMP, IPSec, etc) */
+   ODP_IPSEC_LAYER_L3,
+
+   /** Layer L4 protocols (UDP, TCP, SCTP) */
+   ODP_IPSEC_LAYER_L4,
+
+   /** All layers */
+   ODP_IPSEC_LAYER_ALL
+
+} odp_ipsec_proto_layer_t;
+
+/**
  * Configuration options for IPSEC inbound processing
  */
 typedef struct odp_ipsec_inbound_config_t { @@ -77,9 +111,113 @@ typedef 
struct odp_ipsec_inbound_config_t {
uint32_t max;
} spi;
 
+   /** Retain outer headers
+*
+*  Select up to which protocol layer (at least) outer headers are
+*  retained in inbound inline processing. Default value is
+*  ODP_IPSEC_LAYER_NONE.
+*
+*  ODP_IPSEC_LAYER_NONE: Application does not require any outer
+*headers to be retained.
+*
+*  ODP_IPSEC_LAYER_L2:   Retain headers up to layer 2.
+*
+*  ODP_IPSEC_LAYER_L3:   Retain headers up to layer 3, otherwise the
+*same as ODP_IPSEC_LAYER_ALL.
+*
+*  ODP_IPSEC_LAYER_L4:   Retain headers up to layer 4, otherwise the
+*same as ODP_IPSEC_LAYER_ALL.
+*
+*  ODP_IPSEC_LAYER_ALL:  In tunnel mode, all headers before IPSEC are
+*retained. In transport mode, all headers
+*

Re: [lng-odp] [API-NEXT PATCH v2 2/3] api: ipsec: add inline IPSEC support

[Bala Manoharan]

Regards,
Bala

On 21 March 2017 at 19:47, Petri Savolainen  wrote:
>
> Added support for inline IPSEC processing on packet input and
> output. Inline mode IPSEC and traffic manager cannot be enabled
> (currently) on the same pktio interface.
>
> Signed-off-by: Petri Savolainen 
> ---
>  include/odp/api/spec/ipsec.h | 348 
> ---
>  include/odp/api/spec/packet_io.h |  32 
>  2 files changed, 355 insertions(+), 25 deletions(-)
>
> diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h
> index e951e49..23d02cf 100644
> --- a/include/odp/api/spec/ipsec.h
> +++ b/include/odp/api/spec/ipsec.h
> @@ -19,6 +19,8 @@ extern "C" {
>  #endif
>
>  #include 
> +#include 
> +#include 
>
>  /** @defgroup odp_ipsec ODP IPSEC
>   *  Operations of IPSEC API.
> @@ -51,11 +53,43 @@ typedef enum odp_ipsec_op_mode_t {
>   * Application uses asynchronous IPSEC operations,
>   * which return results via events.
>   */
> -   ODP_IPSEC_OP_MODE_ASYNC
> +   ODP_IPSEC_OP_MODE_ASYNC,
> +
> +   /** Inline IPSEC operation
> + *
> + * Packet input/output is connected directly to IPSEC 
> inbound/outbound
> + * processing. Application uses asynchronous or inline IPSEC
> + * operations.
> + */
> +   ODP_IPSEC_OP_MODE_INLINE,
> +
> +   /** IPSEC is disabled in inbound / outbound direction */
> +   ODP_IPSEC_OP_MODE_DISABLED
>
>  } odp_ipsec_op_mode_t;
>
>  /**
> + * Protocol layers in IPSEC configuration
> + */
> +typedef enum odp_ipsec_proto_layer_t {
> +   /** No layers */
> +   ODP_IPSEC_LAYER_NONE = 0,
> +
> +   /** Layer L2 protocols (Ethernet, VLAN, etc) */
> +   ODP_IPSEC_LAYER_L2,
> +
> +   /** Layer L3 protocols (IPv4, IPv6, ICMP, IPSec, etc) */
> +   ODP_IPSEC_LAYER_L3,
> +
> +   /** Layer L4 protocols (UDP, TCP, SCTP) */
> +   ODP_IPSEC_LAYER_L4,
> +
> +   /** All layers */
> +   ODP_IPSEC_LAYER_ALL
> +
> +} odp_ipsec_proto_layer_t;
> +
> +/**
>   * Configuration options for IPSEC inbound processing
>   */
>  typedef struct odp_ipsec_inbound_config_t {
> @@ -77,9 +111,113 @@ typedef struct odp_ipsec_inbound_config_t {
> uint32_t max;
> } spi;
>
> +   /** Retain outer headers
> +*
> +*  Select up to which protocol layer (at least) outer headers are
> +*  retained in inbound inline processing. Default value is
> +*  ODP_IPSEC_LAYER_NONE.
> +*
> +*  ODP_IPSEC_LAYER_NONE: Application does not require any outer
> +*headers to be retained.
> +*
> +*  ODP_IPSEC_LAYER_L2:   Retain headers up to layer 2.
> +*
> +*  ODP_IPSEC_LAYER_L3:   Retain headers up to layer 3, otherwise the
> +*same as ODP_IPSEC_LAYER_ALL.
> +*
> +*  ODP_IPSEC_LAYER_L4:   Retain headers up to layer 4, otherwise the
> +*same as ODP_IPSEC_LAYER_ALL.
> +*
> +*  ODP_IPSEC_LAYER_ALL:  In tunnel mode, all headers before IPSEC are
> +*retained. In transport mode, all headers
> +*before IP (carrying IPSEC) are retained.
> +*
> +*/
> +   odp_ipsec_proto_layer_t retain_outer;
> +
> +   /** Parse packet headers in IPSEC payload
> +*
> +*  Select header parsing level after inbound processing. Packet 
> headers
> +*  in IPSEC payload must be parsed (at least) up to this level.
> +*  Default value is ODP_IPSEC_LAYER_NONE.
> +*
> +*  Note that IPSec payload is never a L2 packet (ODP_IPSEC_LAYER_L2
> +*  equals ODP_IPSEC_LAYER_NONE). In transport mode, IPSEC payload
> +*  starts after IP header (ODP_IPSEC_LAYER_L3 equals
> +*  ODP_IPSEC_LAYER_NONE).
> +*/
> +   odp_ipsec_proto_layer_t parse;
> +
> +   /** Flags to control IPSEC payload data checks up to the selected 
> parse
> +*  level. */
> +   union {
> +   struct {
> +   /** Check IPv4 header checksum in IPSEC payload.
> +*  Default value is 0. */
> +   uint32_t ipv4_chksum   : 1;
> +
> +   /** Check UDP checksum in IPSEC payload.
> +*  Default value is 0. */
> +   uint32_t udp_chksum: 1;
> +
> +   /** Check TCP checksum in IPSEC payload.
> +*  Default value is 0. */
> +   uint32_t tcp_chksum: 1;
> +
> +   /** Check SCTP checksum in IPSEC payload.
> +*  Default value is 0. */
> +   uint32_t sctp_chksum   : 1;
> +   } check;
> +
> +   /** All bits of the bit field structure
> +  

Re: [lng-odp] [API-NEXT PATCH v2 2/3] api: ipsec: add inline IPSEC support

[Savolainen, Petri (Nokia - FI/Espoo)]

NO HTML mails to the ODP list please. Indentation is lost due to HTML.


 /**
+ * Protocol layers in IPSEC configuration
+ */
+typedef enum odp_ipsec_proto_layer_t {
+       /** No layers */
+       ODP_IPSEC_LAYER_NONE = 0,
+
+       /** Layer L2 protocols (Ethernet, VLAN, etc) */
+       ODP_IPSEC_LAYER_L2,
+
+       /** Layer L3 protocols (IPv4, IPv6, ICMP, IPSec, etc) */

Nit: Correct spelling is IPsec, not IPSec, per RFC 4301.

+       /** Parse packet headers in IPSEC payload
+        *
+        *  Select header parsing level after inbound processing. Packet headers
+        *  in IPSEC payload must be parsed (at least) up to this level.
+        *  Default value is ODP_IPSEC_LAYER_NONE.
+        *
+        *  Note that IPSec payload is never a L2 packet (ODP_IPSEC_LAYER_L2

IPsec


OK. I'll correct it to IPSEC, which is used throughout this file.

" All other capitalizations of IPsec (e.g., IPSEC, IPSec, ipsec) are 
deprecated. However, any capitalization of the  sequence of letters "IPsec" 
should be understood to refer to the IPsec protocols. "

 
+/**
  * IPSEC Security Association (SA) parameters
  */
 typedef struct odp_ipsec_sa_param_t {
@@ -426,6 +610,17 @@ typedef struct odp_ipsec_sa_param_t {
        /** SPI value */
        uint32_t spi;

+       /** Additional inbound SA lookup parameters. Values are considered
+        *  only in ODP_IPSEC_LOOKUP_IN_DSTADDR_UNIQUE_SPI lookup mode. */
+       struct {
+               /* v4 or v6 */
+               uint8_t ip_version;

Is this an enum? If not perhaps doc this as 4 = IPv4, 6 = IPv6.

OK. I'll document it.

 

 /**
+ * Outbound inline IPSEC operation parameters
+ */
+typedef struct odp_ipsec_inline_op_param_t {
+       /** Packet output interface for inline output operation
+        *
+        *  Outbound inline IPSEC operation uses this packet IO interface to
+        *  output the packet after a successful IPSEC transformation. The pktio
+        *  must have been configured to operate in inline IPSEC mode.
+        */
+       odp_pktio_t pktio;

Shouldn't we have an option for this to be output to an odp_tm_queue_t instead 
of a pktio? 
Also, for output are there any controls over which odp_pktout_queue_t is used, 
or is this undefined?


TM is not supported at this stage. Destination TM queue will be added here when 
TM support is added.

Pktout queues are for application use, there's no benefit from those to an 
accelerator (IPSEC may use whatever  implementation specific way to deliver 
packet to pktio).

 
+
+       /** Outer headers for inline output operation
+        *
+        *  Outbound inline IPSEC operation uses this information to prepend
+        *  outer headers to the IPSEC packet before sending it out.
+        */
+       struct {
+               /** Points to first byte of outer headers to be copied in
+                *  front of the outgoing IPSEC packet. Implementation copies
+                *  the headers during odp_ipsec_out_inline() call. */
+               uint8_t *ptr;

Should this be an odp_packet_t rather than a raw set of bytes? The rationale 
for making this an odp_packet_t is that this could then be a packet reference 
which can be used for (re)transmit tracking. For input having this be raw bytes 
makes sense since the ODP implementation is controlling their allocation and 
placement, however for output how is the application going to allocate these? 
Presumably it would create a header via odp_packet_alloc() and then use 
odp_packet_data() to get this address, but that seems cumbersome compared to 
simply passing the odp_packet_t directly. The alternative would seem to require 
that the application use some sort of odp_shm_reserve() call, but that gets 
awkward and is far less efficient than packet allocation, which is a fastpath 
operation.
 

Packet is not needed for l2 hdr storage. Application will store headers to e.g. 
SA context, etc convenient memory location and pass only a pointer to there. 
Implementation copies those (few) bytes during odp_ipsec_out_inline() call. 
Since headers are copied, there's no special requirement for the memory - also 
stack can be used. Most likely application would not store the headers into a 
packet - since there's no benefit on doing so. The payload packet would be more 
likely target for reference counting (than l2 hdr bytes).


 /**
@@ -773,18 +1045,14 @@ typedef struct odp_ipsec_op_result_t {
         *  at least 'num_pkt' elements.
         *
         *  Each successfully transformed packet has a valid value for these
-        *  meta-data:
+        *  meta-data regardless of the inner packet parse configuration.

Vestigial typo. It's metadata, not meta-data. Might as well clean up here.

OK.

+
+       /** Outbound IPSEC inlined with packet output
+        *
+        *  Enable/disable inline outbound IPSEC operation. When enabled IPSEC
+        *  outbound processing can send outgoing IPSEC packets directly
+        *  to the pktio interface for output. 

Re: [lng-odp] [API-NEXT PATCH v2 2/3] api: ipsec: add inline IPSEC support

[Peltonen, Janne (Nokia - FI/Espoo)]

Hi,

> > +
> > +   /** Outer headers for inline output operation
> > +*
> > +*  Outbound inline IPSEC operation uses this information to
> > prepend
> > +*  outer headers to the IPSEC packet before sending it out.
> > +*/
> > +   struct {
> > +   /** Points to first byte of outer headers to be copied in
> > +*  front of the outgoing IPSEC packet. Implementation
> > copies
> > +*  the headers during odp_ipsec_out_inline() call. */
> > +   uint8_t *ptr;
> >
> 
> Should this be an odp_packet_t rather than a raw set of bytes? The
> rationale for making this an odp_packet_t is that this could then be a
> packet reference which can be used for (re)transmit tracking. For input

If it were odp_packet_t, the IPsec implementation would have to be
prepared for the data to be segmented in arbitrary ways, which probably
would not improve performance. And to me it is not really a packet anyway.

I did not quite understand the point about retransmit tracking in this
context.

One thing we already discussed with Petri is that to enable IP and UDP
based tunneling protocols (e.g. IPIP, GRE, VxLAN) outside the IPsec
packet in the inline output case, the right packet length would have
to be inserted in the right place of the added header. There is the
same issue with L2 protocols that would contain the total packet
length (e.g. some proprietary fabric encapsulation). In this case
the outer header is rather like a template. This is something to be
considered in some future versions of the API but one possible
way to accommodate some of these cases is to have an offset that
specifies which word of the complete packet shall be incremented
by the resulting packet size after IPsec encapsulation.

> having this be raw bytes makes sense since the ODP implementation is
> controlling their allocation and placement, however for output how is the
> application going to allocate these? Presumably it would create a header
> via odp_packet_alloc() and then use odp_packet_data() to get this address,
> but that seems cumbersome compared to simply passing the odp_packet_t
> directly. The alternative would seem to require that the application use
> some sort of odp_shm_reserve() call, but that gets awkward and is far less
> efficient than packet allocation, which is a fastpath operation.
>

I do not think applications would dynamically allocate the storage for the
header (through packet alloc or shm alloc or whatever) for every packet sent
but would just have the pointer point to a cached header somewhere (e.g.
ready-made L2 header cached in the next hop structure found by L3 route
search). If the header or part of it does have to be constructed on the
fly, the application can use the stack or other thread specific storage
that does not have to be allocated separately for every output operation.
Or maybe even some existing per-packet memory like the user area.

Btw, the API should make it clear if the header data can be in the headroom
or the user area of the packet being enqueued (I suppose the latter should
be fine).
 
Janne


> -Original Message-
> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Bill 
> Fischofer
> Sent: Wednesday, March 22, 2017 12:17 AM
> To: Petri Savolainen <petri.savolai...@linaro.org>
> Cc: lng-odp-forward <lng-odp@lists.linaro.org>
> Subject: Re: [lng-odp] [API-NEXT PATCH v2 2/3] api: ipsec: add inline IPSEC 
> support
> 
> On Tue, Mar 21, 2017 at 9:17 AM, Petri Savolainen <
> petri.savolai...@linaro.org> wrote:
> 
> > Added support for inline IPSEC processing on packet input and
> > output. Inline mode IPSEC and traffic manager cannot be enabled
> > (currently) on the same pktio interface.
> >
> > Signed-off-by: Petri Savolainen <petri.savolai...@linaro.org>
> > ---
> >  include/odp/api/spec/ipsec.h | 348 ++
> > ++---
> >  include/odp/api/spec/packet_io.h |  32 
> >  2 files changed, 355 insertions(+), 25 deletions(-)
> >
> > diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h
> > index e951e49..23d02cf 100644
> > --- a/include/odp/api/spec/ipsec.h
> > +++ b/include/odp/api/spec/ipsec.h
> > @@ -19,6 +19,8 @@ extern "C" {
> >  #endif
> >
> >  #include 
> > +#include 
> > +#include 
> >
> >  /** @defgroup odp_ipsec ODP IPSEC
> >   *  Operations of IPSEC API.
> > @@ -51,11 +53,43 @@ typedef enum odp_ipsec_op_mode_t {
> >   * Application uses asynchronous IPSEC operations,
> >   * which return results via events.
> >   */
> > - 

Re: [lng-odp] [API-NEXT PATCH v2 2/3] api: ipsec: add inline IPSEC support

[Bill Fischofer]

On Tue, Mar 21, 2017 at 9:17 AM, Petri Savolainen <
petri.savolai...@linaro.org> wrote:

> Added support for inline IPSEC processing on packet input and
> output. Inline mode IPSEC and traffic manager cannot be enabled
> (currently) on the same pktio interface.
>
> Signed-off-by: Petri Savolainen 
> ---
>  include/odp/api/spec/ipsec.h | 348 ++
> ++---
>  include/odp/api/spec/packet_io.h |  32 
>  2 files changed, 355 insertions(+), 25 deletions(-)
>
> diff --git a/include/odp/api/spec/ipsec.h b/include/odp/api/spec/ipsec.h
> index e951e49..23d02cf 100644
> --- a/include/odp/api/spec/ipsec.h
> +++ b/include/odp/api/spec/ipsec.h
> @@ -19,6 +19,8 @@ extern "C" {
>  #endif
>
>  #include 
> +#include 
> +#include 
>
>  /** @defgroup odp_ipsec ODP IPSEC
>   *  Operations of IPSEC API.
> @@ -51,11 +53,43 @@ typedef enum odp_ipsec_op_mode_t {
>   * Application uses asynchronous IPSEC operations,
>   * which return results via events.
>   */
> -   ODP_IPSEC_OP_MODE_ASYNC
> +   ODP_IPSEC_OP_MODE_ASYNC,
> +
> +   /** Inline IPSEC operation
> + *
> + * Packet input/output is connected directly to IPSEC
> inbound/outbound
> + * processing. Application uses asynchronous or inline IPSEC
> + * operations.
> + */
> +   ODP_IPSEC_OP_MODE_INLINE,
> +
> +   /** IPSEC is disabled in inbound / outbound direction */
> +   ODP_IPSEC_OP_MODE_DISABLED
>
>  } odp_ipsec_op_mode_t;
>
>  /**
> + * Protocol layers in IPSEC configuration
> + */
> +typedef enum odp_ipsec_proto_layer_t {
> +   /** No layers */
> +   ODP_IPSEC_LAYER_NONE = 0,
> +
> +   /** Layer L2 protocols (Ethernet, VLAN, etc) */
> +   ODP_IPSEC_LAYER_L2,
> +
> +   /** Layer L3 protocols (IPv4, IPv6, ICMP, IPSec, etc) */
>

Nit: Correct spelling is IPsec, not IPSec, per RFC 4301.


> +   ODP_IPSEC_LAYER_L3,
> +
> +   /** Layer L4 protocols (UDP, TCP, SCTP) */
> +   ODP_IPSEC_LAYER_L4,
> +
> +   /** All layers */
> +   ODP_IPSEC_LAYER_ALL
> +
> +} odp_ipsec_proto_layer_t;
> +
> +/**
>   * Configuration options for IPSEC inbound processing
>   */
>  typedef struct odp_ipsec_inbound_config_t {
> @@ -77,9 +111,113 @@ typedef struct odp_ipsec_inbound_config_t {
> uint32_t max;
> } spi;
>
> +   /** Retain outer headers
> +*
> +*  Select up to which protocol layer (at least) outer headers are
> +*  retained in inbound inline processing. Default value is
> +*  ODP_IPSEC_LAYER_NONE.
> +*
> +*  ODP_IPSEC_LAYER_NONE: Application does not require any outer
> +*headers to be retained.
> +*
> +*  ODP_IPSEC_LAYER_L2:   Retain headers up to layer 2.
> +*
> +*  ODP_IPSEC_LAYER_L3:   Retain headers up to layer 3, otherwise
> the
> +*same as ODP_IPSEC_LAYER_ALL.
> +*
> +*  ODP_IPSEC_LAYER_L4:   Retain headers up to layer 4, otherwise
> the
> +*same as ODP_IPSEC_LAYER_ALL.
> +*
> +*  ODP_IPSEC_LAYER_ALL:  In tunnel mode, all headers before IPSEC
> are
> +*retained. In transport mode, all headers
> +*before IP (carrying IPSEC) are retained.
> +*
> +*/
> +   odp_ipsec_proto_layer_t retain_outer;
> +
> +   /** Parse packet headers in IPSEC payload
> +*
> +*  Select header parsing level after inbound processing. Packet
> headers
> +*  in IPSEC payload must be parsed (at least) up to this level.
> +*  Default value is ODP_IPSEC_LAYER_NONE.
> +*
> +*  Note that IPSec payload is never a L2 packet
> (ODP_IPSEC_LAYER_L2
>

IPsec


> +*  equals ODP_IPSEC_LAYER_NONE). In transport mode, IPSEC payload
> +*  starts after IP header (ODP_IPSEC_LAYER_L3 equals
> +*  ODP_IPSEC_LAYER_NONE).
> +*/
> +   odp_ipsec_proto_layer_t parse;
> +
> +   /** Flags to control IPSEC payload data checks up to the selected
> parse
> +*  level. */
> +   union {
> +   struct {
> +   /** Check IPv4 header checksum in IPSEC payload.
> +*  Default value is 0. */
> +   uint32_t ipv4_chksum   : 1;
> +
> +   /** Check UDP checksum in IPSEC payload.
> +*  Default value is 0. */
> +   uint32_t udp_chksum: 1;
> +
> +   /** Check TCP checksum in IPSEC payload.
> +*  Default value is 0. */
> +   uint32_t tcp_chksum: 1;
> +
> +   /** Check SCTP checksum in IPSEC payload.
> +*  Default value is 0. */
> +   uint32_t sctp_chksum   : 1;
> +   }