DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] [RFC 0/7] ipsec inline
@ 2017-07-10  7:35 Boris Pismenny
  2017-07-10  7:35 ` [dpdk-dev] [RFC 1/7] ethdev: add device ipsec encrypt/decrypt capability flags Boris Pismenny
                   ` (7 more replies)
  0 siblings, 8 replies; 37+ messages in thread
From: Boris Pismenny @ 2017-07-10  7:35 UTC (permalink / raw)
  To: dev; +Cc: aviadye, borisp

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 9993 bytes --]

In this RFC we introduce a infrastructure for IPSec inline hardware offloading.
This RFC introduces device capabilities, configuration API and data path
processing. We also provide a comparison with a previous RFC posted on the list
for this feature.

1. Inline crypto processing 
1.1. Device Capabilities:
    o DEV_RX_OFFLOAD_IPSEC_CRYPTO            - device support inline ipsec
    decryption offload.
    o DEV_TX_OFFLOAD_IPSEC_CRYPTO_HW_TRAILER - device support inline ipsec
    encrypted offload, ipsec trailer is added by hardware.
    o DEV_TX_OFFLOAD_IPSEC_CRYPTO_TSO        - device support inline ipsec
    encrypted offload within segment large packets, ipsec trailer is added by
    hardware to each segment.

1.2. Configuration API:
    We will modify steering API in order to add IPsec transform actions.

    o Definition of ESP header: 
    
    struct esp_hdr {
        int32_t spi;  /**< Security Parameters Index */
        uint32_t seq;  /**< packet sequence number */
    } __attribute__((__packed__));

    o New flow item:

    enum rte_flow_item_type {
        ...

        /**
         * Matches a ESP header.
         *
         * See struct rte_flow_item_esp.
         */
        RTE_FLOW_ITEM_TYPE_ESP,
    };
    
    struct rte_flow_item_esp {
        struct esp_hdr hdr; /**< ESP header definition. */
    };

    struct rte_flow_item_esp {
        static const struct rte_flow_item_esp rte_flow_item_esp_mask = {
        .hdr = {
            .spi = 0xffffffff,
        },
    };

    o New ipsec transform:
    struct rte_crypto_ipsec_xform {
        enum rte_crypto_cipher_operation op;
        enum rte_crypto_cipher_algorithm algo;

        struct {
            uint8_t *data;    /**< pointer to key data */
            size_t length;    /**< key length in bytes */
        } key;

        uint32_t salt; /* salt for this security association */
    };

    /** Crypto transformation types */
    enum rte_crypto_sym_xform_type {
        ...
        RTE_CRYPTO_SYM_XFORM_CIPHER,    /**< Cipher xform  */
        RTE_CRYPTO_SYM_XFORM_IPSEC,        /**< IPsec xform  */
    };

    struct rte_crypto_sym_xform {
        ...
        struct rte_crypto_ipsec_xform ipsec;
        /**< IPsec xform */
    };
 

    o New flow action:
    
    enum rte_flow_action_type {
        ...

        /**
         * Encrypts or decrypts packets matching this flow. Must be either egress
         * or ingress, but not both.
         *
         * See struct rte_flow_action_crypto.
         */
        RTE_FLOW_ACTION_TYPE_CRYPTO,
    };

    struct rte_flow_action_crypto {
        struct rte_crypto_sym_xform xform; /* applied crypto transform */
    };

        
 Configuration Path
         |
+--------|--------+
|    Add/Remove   |
|     IPsec SA    |   <------ Build crypto flow action of ipsec transform
|        |        |
|--------|--------|
         |
+--------V--------+
|   Flow API      |
+--------|--------+
         |
+--------V--------+
|                 |
|     NIC PMD     |   <------ Add/Remove SA to/from hw context
|                 |
+--------|--------+
         |
+--------|--------+
|  HW ACCELERATED |
|        NIC      |
|                 |
+--------|--------+

o Add/Delete SA flow:
    To add a new inline SA construct a rte_flow_item for Ethernet + IP + ESP
    using the SA selectors and the rte_crypto_ipsec_xform as the rte_flow_action.
    Note that any rte_flow_items may be empty, which means it is not checked.

    In its most basic form, IPsec flow specification is as follows:
+-------+     +----------+    +--------+    +-----+ 
|  Eth  | ->  |   IP4/6  | -> |   ESP  | -> | END |
+-------+     +----------+    +--------+    +-----+ 

    However, the API can represent, IPsec crypto offload with any encapsulation:

+-------+            +--------+    +-----+
|  Eth  | ->  ... -> |   ESP  | -> | END |
+-------+            +--------+    +-----+

1.3. Data Path Processing:

1.3.1. mbuf Changes
    o New rx mbuf offload flags to indicate that a packet has gone through
    inline crypto processing on to the NIC PMD and the result of this processing.
    On failure, packets should be dropped.
    /**
     * Mask of bits used to determine the status of RX IPsec crypto.
     * - PKT_RX_IPSEC_CRYPTO_UNKNOWN     : no information about the RX IPsec crypto
     * - PKT_RX_IPSEC_CRYPTO »           : decryption and authentication were performed
     * - PKT_RX_IPSEC_CRYPTO_FAILED      : ipsec processing failed
     */
    #define PKT_RX_IPSEC_CRYPTO_UNKNOWN         0
    #define PKT_RX_IPSEC_CRYPTO                 (1ULL << 18)
    #define PKT_RX_IPSEC_CRYPTO_FAILED          (1ULL << 19)
            
    o New tx mbuf offload flags to indicate that a packet requires IPsec inline
    crypto processing and trailer construction on the NIC PMD.

    /**
     * Offload the IPsec encryption with software provided trailer.
     * This flag must be set by the application to enable this
     * offload feature for a packet to be transmitted.
     */
    #define PKT_TX_IPSEC_CRYPTO        (1ULL << 42)

    /**
       * Offload the IPsec encryption and trailer construction. This flag must
       * be set by the application to enable this offload feature for a packet
       * to be transmitted.
       */
      #define PKT_TX_IPSEC_CRYPTO_HW_TRAILER     (1ULL << 43)


  Egress Data Path
          |
+--------|--------+
|  egress IPsec   |
|        |        |
| +------V------+ |
| | SABD lookup | |
| +------|------+ |
| +------V------+ |
| |   Tunnel    | |   <------ Add tunnel header to packet
| +------|------+ |
| +------V------+ |
| |     ESP     | |   <------ Add ESP header without trailer to packet
| |             | |   <------ Mark packet to be offloaded, add trailer meta-data
| +------|------+ |              to mbuf
+--------V--------+
         |
+--------V--------+
|    L2 Stack     |
+--------|--------+
         |
+--------V--------+
|                 |
|     NIC PMD     |   <------ Set hw context for inline crypto offload
|                 |
+--------|--------+
         |
+--------|--------+
|  HW ACCELERATED |   <------ Packet Encryption/Decryption and
|        NIC      |           Authentication happens inline
|                 |
+--------|--------+



2. IPsec Gateway Sample Application
    2.1. Add/Delete SA
    SAs are configured as previously via the configuration file, the user could
    specify which SAs require inline offload by adding "offload" for that SA.
    We then store for each SA whether it is offloaded in the ipsec_sa structure.
    Additionally, we extended the ipsec_sa structure with additional fields
    related to rte_flow, which are initialized if offload is requested.
    
        struct ipsec_sa {
        ...
            #define MAX_RTE_FLOW_PATTERN (4)
            // ETH + IP + ESP + END
            union {
                    struct rte_flow_item_ipv4 ipv4;
                    struct rte_flow_item_ipv6 ipv6;
            } ip_spec;
            struct rte_flow_item_esp esp_spec;
            struct rte_flow_item pattern[MAX_RTE_FLOW_PATTERN];
            #define MAX_RTE_FLOW_ACTIONS (3)
            struct rte_flow_action_crypto crypto_action;
            struct rte_flow_action action[MAX_RTE_FLOW_ACTIONS];
            struct rte_flow *flow;
        ...
            int offload;
            #define OFFLOAD_ENABLED  1
            #define OFFLOAD_DISABLED 0
        ...
        };
    
    When a user attempts to crete a session it checks whether inline offload is
    needed. If yes, then rte_flow_create is called with the parameters
    initialized above. In any case, create_session_cryptodev is called. The
    cryptodev session is used to handle software fallback for packets that are
    not processed by hardware.
    
3. Comparison with previous RFC
    In the section we compare the previous RFC
    (http://dpdk.org/ml/archives/dev/2017-May/065513.html)
    with this RFC.

    The main difference is in NIC capabilities. Mellanox hardware
    is capable of applying IPsec inline based on packet pattern, while
    intel use mbuf metadata. This API allows application to save cycles
    by not storing metadata on each packet mbuf, but instead store metadata
    once per flow.

    Another difference is the use of Crypto PMD for inline IPsec vs.
    NIC PMD. Using the NIC PMD has several advantages. First, configuration
    is simpler - crypto is performed by the same device to which packets
    are routed, and there is no chance for configuring a crypto context on
    one device and routing packets to another device and transmitting
    plaintext as a result. Second, Crypto PMD semantics imply that data has
    been processed after dequeue. This is not true for inline IPsec, where
    data is processed only when it goes through the NIC. Finally, using the
    NIC PMD directly has better performance, because the Crypto PMD code is
    not involved.

Aviad Yehezkel (2):
  mbuf: Added next_esp_proto field
  example/ipsec_gw: Support SA offload in datapath

Boris Pismenny (5):
  ethdev: add device ipsec encrypt/decrypt capability flags
  ethdev: Add ESP header to generic flow steering
  ethdev: add rte flow action for crypto
  cryptodev: add ipsec xform
  mbuf: Add IPsec crypto flags

 examples/ipsec-secgw/esp.c            |  68 ++++++++++++----
 examples/ipsec-secgw/esp.h            |  13 +---
 examples/ipsec-secgw/ipsec.c          | 142 +++++++++++++++++++++++++++++-----
 examples/ipsec-secgw/ipsec.h          |  30 +++++++
 examples/ipsec-secgw/sa.c             | 120 ++++++++++++++++++++++++----
 lib/Makefile                          |   1 +
 lib/librte_cryptodev/rte_crypto_sym.h |  42 +++++++++-
 lib/librte_ether/rte_ethdev.h         |   4 +
 lib/librte_ether/rte_flow.h           |  50 ++++++++++++
 lib/librte_mbuf/rte_mbuf.c            |  16 ++++
 lib/librte_mbuf/rte_mbuf.h            |  38 ++++++++-
 lib/librte_net/Makefile               |   2 +-
 12 files changed, 466 insertions(+), 60 deletions(-)

-- 
1.8.3.1

^ permalink raw reply	[flat|nested] 37+ messages in thread

end of thread, other threads:[~2017-09-11 18:10 UTC | newest]

Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-07-10  7:35 [dpdk-dev] [RFC 0/7] ipsec inline Boris Pismenny
2017-07-10  7:35 ` [dpdk-dev] [RFC 1/7] ethdev: add device ipsec encrypt/decrypt capability flags Boris Pismenny
2017-07-10  7:35 ` [dpdk-dev] [RFC 2/7] ethdev: Add ESP header to generic flow steering Boris Pismenny
2017-07-10  7:35 ` [dpdk-dev] [RFC 3/7] ethdev: add rte flow action for crypto Boris Pismenny
2017-07-10  7:35 ` [dpdk-dev] [RFC 4/7] cryptodev: add ipsec xform Boris Pismenny
2017-07-10  7:35 ` [dpdk-dev] [RFC 5/7] mbuf: Add IPsec crypto flags Boris Pismenny
2017-07-10  7:35 ` [dpdk-dev] [RFC 6/7] mbuf: Added next_esp_proto field Boris Pismenny
2017-07-10  7:35 ` [dpdk-dev] [RFC 7/7] example/ipsec_gw: Support SA offload in datapath Boris Pismenny
2017-07-11 17:06 ` [dpdk-dev] [RFC 0/7] ipsec inline Declan Doherty
2017-07-12 14:08   ` Boris Pismenny
2017-07-14 11:12   ` Akhil Goyal
2017-07-25 11:21     ` [dpdk-dev] [RFC PATCH 0/1] IPSec Inline and look aside crypto offload Akhil Goyal
2017-07-25 11:21       ` [dpdk-dev] [RFC PATCH 1/1] rte_security: proposal Akhil Goyal
2017-07-26 13:46       ` [dpdk-dev] [RFC PATCH 0/1] IPSec Inline and look aside crypto offload Declan Doherty
2017-08-02 13:16         ` Hemant Agrawal
2017-08-03 11:25           ` Akhil Goyal
2017-08-15  6:35       ` [dpdk-dev] [RFC PATCH v2 0/4] " Akhil Goyal
2017-08-15  6:35         ` [dpdk-dev] [RFC PATCH 1/4] rte_security: API definitions Akhil Goyal
2017-08-15 11:04           ` Radu Nicolau
2017-08-16  7:39             ` Akhil Goyal
2017-08-16 15:40               ` Hemant Agrawal
2017-08-18  9:16                 ` Thomas Monjalon
2017-08-18 12:20                   ` Hemant Agrawal
2017-08-21 10:32                   ` Boris Pismenny
2017-08-21 10:54                     ` Akhil Goyal
2017-08-15  6:35         ` [dpdk-dev] [RFC PATCH 2/4] cryptodev: entend cryptodev to support security APIs Akhil Goyal
2017-08-15  6:35         ` [dpdk-dev] [RFC PATCH 3/4] crypto/dpaa2_sec: add support for protocol offload ipsec Akhil Goyal
2017-08-15  6:35         ` [dpdk-dev] [RFC PATCH 4/4] example/ipsec-secgw: add support for offloading crypto op Akhil Goyal
2017-08-29 14:49       ` [dpdk-dev] [RFC PATCH 0/1] IPSec Inline and look aside crypto offload Thomas Monjalon
2017-08-31  9:37         ` Akhil Goyal
2017-08-31 10:06           ` Thomas Monjalon
2017-08-31 10:52             ` Akhil Goyal
2017-08-31 13:14               ` Thomas Monjalon
2017-08-31 14:09                 ` Radu Nicolau
2017-09-06 15:53                   ` Jerin Jacob
2017-09-08 11:12                     ` Akhil Goyal
2017-09-11 18:10                       ` Jerin Jacob

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).