prog_guide/rte_security.rst

   1 ..  SPDX-License-Identifier: BSD-3-Clause
   2     Copyright 2017,2020 NXP
   3
   4
   5
   6 Security Library
   7 ================
   8
   9 The security library provides a framework for management and provisioning
  10 of security protocol operations offloaded to hardware based devices. The
  11 library defines generic APIs to create and free security sessions which can
  12 support full protocol offload as well as inline crypto operation with
  13 NIC or crypto devices. The framework currently only supports the IPsec, PDCP
  14 and DOCSIS protocols and associated operations, other protocols will be added
  15 in the future.
  16
  17 Design Principles
  18 -----------------
  19
  20 The security library provides an additional offload capability to an existing
  21 crypto device and/or ethernet device.
  22
  23 .. code-block:: console
  24
  25                +---------------+
  26                | rte_security  |
  27                +---------------+
  28                  \            /
  29         +-----------+    +--------------+
  30         |  NIC PMD  |    |  CRYPTO PMD  |
  31         +-----------+    +--------------+
  32
  33 .. note::
  34
  35     Currently, the security library does not support the case of multi-process.
  36     It will be updated in the future releases.
  37
  38 The supported offload types are explained in the sections below.
  39
  40 Inline Crypto
  41 ~~~~~~~~~~~~~
  42
  43 RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO:
  44 The crypto processing for security protocol (e.g. IPsec) is processed
  45 inline during receive and transmission on NIC port. The flow based
  46 security action should be configured on the port.
  47
  48 Ingress Data path - The packet is decrypted in RX path and relevant
  49 crypto status is set in Rx descriptors. After the successful inline
  50 crypto processing the packet is presented to host as a regular Rx packet
  51 however all security protocol related headers are still attached to the
  52 packet. e.g. In case of IPsec, the IPsec tunnel headers (if any),
  53 ESP/AH headers will remain in the packet but the received packet
  54 contains the decrypted data where the encrypted data was when the packet
  55 arrived. The driver Rx path check the descriptors and based on the
  56 crypto status sets additional flags in the rte_mbuf.ol_flags field.
  57
  58 .. note::
  59
  60     The underlying device may not support crypto processing for all ingress packet
  61     matching to a particular flow (e.g. fragmented packets), such packets will
  62     be passed as encrypted packets. It is the responsibility of application to
  63     process such encrypted packets using other crypto driver instance.
  64
  65 Egress Data path - The software prepares the egress packet by adding
  66 relevant security protocol headers. Only the data will not be
  67 encrypted by the software. The driver will accordingly configure the
  68 tx descriptors. The hardware device will encrypt the data before sending the
  69 packet out.
  70
  71 .. note::
  72
  73     The underlying device may support post encryption TSO.
  74
  75 .. code-block:: console
  76
  77           Egress Data Path
  78                  |
  79         +--------|--------+
  80         |  egress IPsec   |
  81         |        |        |
  82         | +------V------+ |
  83         | | SADB lookup | |
  84         | +------|------+ |
  85         | +------V------+ |
  86         | |   Tunnel    | |   <------ Add tunnel header to packet
  87         | +------|------+ |
  88         | +------V------+ |
  89         | |     ESP     | |   <------ Add ESP header without trailer to packet
  90         | |             | |   <------ Mark packet to be offloaded, add trailer
  91         | +------|------+ |            meta-data to mbuf
  92         +--------V--------+
  93                  |
  94         +--------V--------+
  95         |    L2 Stack     |
  96         +--------|--------+
  97                  |
  98         +--------V--------+
  99         |                 |
 100         |     NIC PMD     |   <------ Set hw context for inline crypto offload
 101         |                 |
 102         +--------|--------+
 103                  |
 104         +--------|--------+
 105         |  HW ACCELERATED |   <------ Packet Encryption and
 106         |        NIC      |           Authentication happens inline
 107         |                 |
 108         +-----------------+
 109
 110
 111 Inline protocol offload
 112 ~~~~~~~~~~~~~~~~~~~~~~~
 113
 114 RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL:
 115 The crypto and protocol processing for security protocol (e.g. IPsec)
 116 is processed inline during receive and transmission.  The flow based
 117 security action should be configured on the port.
 118
 119 Ingress Data path - The packet is decrypted in the RX path and relevant
 120 crypto status is set in the Rx descriptors. After the successful inline
 121 crypto processing the packet is presented to the host as a regular Rx packet
 122 but all security protocol related headers are optionally removed from the
 123 packet. e.g. in the case of IPsec, the IPsec tunnel headers (if any),
 124 ESP/AH headers will be removed from the packet and the received packet
 125 will contains the decrypted packet only. The driver Rx path checks the
 126 descriptors and based on the crypto status sets additional flags in
 127 ``rte_mbuf.ol_flags`` field. The driver would also set device-specific
 128 metadata in ``RTE_SECURITY_DYNFIELD_NAME`` field.
 129 This will allow the application to identify the security processing
 130 done on the packet.
 131
 132 .. note::
 133
 134     The underlying device in this case is stateful. It is expected that
 135     the device shall support crypto processing for all kind of packets matching
 136     to a given flow, this includes fragmented packets (post reassembly).
 137     E.g. in case of IPsec the device may internally manage anti-replay etc.
 138     It will provide a configuration option for anti-replay behavior i.e. to drop
 139     the packets or pass them to driver with error flags set in the descriptor.
 140
 141 Egress Data path - The software will send the plain packet without any
 142 security protocol headers added to the packet. The driver will configure
 143 the security index and other requirement in tx descriptors.
 144 The hardware device will do security processing on the packet that includes
 145 adding the relevant protocol headers and encrypting the data before sending
 146 the packet out. The software should make sure that the buffer
 147 has required head room and tail room for any protocol header addition. The
 148 software may also do early fragmentation if the resultant packet is expected
 149 to cross the MTU size.
 150
 151
 152 .. note::
 153
 154     The underlying device will manage state information required for egress
 155     processing. E.g. in case of IPsec, the seq number will be added to the
 156     packet, however the device shall provide indication when the sequence number
 157     is about to overflow. The underlying device may support post encryption TSO.
 158
 159 .. code-block:: console
 160
 161          Egress Data Path
 162                  |
 163         +--------|--------+
 164         |  egress IPsec   |
 165         |        |        |
 166         | +------V------+ |
 167         | | SADB lookup | |
 168         | +------|------+ |
 169         | +------V------+ |
 170         | |   Desc      | |   <------ Mark packet to be offloaded
 171         | +------|------+ |
 172         +--------V--------+
 173                  |
 174         +--------V--------+
 175         |    L2 Stack     |
 176         +--------|--------+
 177                  |
 178         +--------V--------+
 179         |                 |
 180         |     NIC PMD     |   <------ Set hw context for inline crypto offload
 181         |                 |
 182         +--------|--------+
 183                  |
 184         +--------|--------+
 185         |  HW ACCELERATED |   <------ Add tunnel, ESP header etc header to
 186         |        NIC      |           packet. Packet Encryption and
 187         |                 |           Authentication happens inline.
 188         +-----------------+
 189
 190
 191 Lookaside protocol offload
 192 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 193
 194 RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL:
 195 This extends librte_cryptodev to support the programming of IPsec
 196 Security Association (SA) as part of a crypto session creation including
 197 the definition. In addition to standard crypto processing, as defined by
 198 the cryptodev, the security protocol processing is also offloaded to the
 199 crypto device.
 200
 201 Decryption: The packet is sent to the crypto device for security
 202 protocol processing. The device will decrypt the packet and it will also
 203 optionally remove additional security headers from the packet.
 204 E.g. in case of IPsec, IPsec tunnel headers (if any), ESP/AH headers
 205 will be removed from the packet and the decrypted packet may contain
 206 plain data only.
 207
 208 .. note::
 209
 210     In case of IPsec the device may internally manage anti-replay etc.
 211     It will provide a configuration option for anti-replay behavior i.e. to drop
 212     the packets or pass them to driver with error flags set in descriptor.
 213
 214 Encryption: The software will submit the packet to cryptodev as usual
 215 for encryption, the hardware device in this case will also add the relevant
 216 security protocol header along with encrypting the packet. The software
 217 should make sure that the buffer has required head room and tail room
 218 for any protocol header addition.
 219
 220 .. note::
 221
 222     In the case of IPsec, the seq number will be added to the packet,
 223     It shall provide an indication when the sequence number is about to
 224     overflow.
 225
 226 .. code-block:: console
 227
 228           Egress Data Path
 229                  |
 230         +--------|--------+
 231         |  egress IPsec   |
 232         |        |        |
 233         | +------V------+ |
 234         | | SADB lookup | |   <------ SA maps to cryptodev session
 235         | +------|------+ |
 236         | +------|------+ |
 237         | |      \--------------------\
 238         | |    Crypto   | |           |  <- Crypto processing through
 239         | |      /----------------\   |     inline crypto PMD
 240         | +------|------+ |       |   |
 241         +--------V--------+       |   |
 242                  |                |   |
 243         +--------V--------+       |   |  create   <-- SA is added to hw
 244         |    L2 Stack     |       |   |  inline       using existing create
 245         +--------|--------+       |   |  session      sym session APIs
 246                  |                |   |    |
 247         +--------V--------+   +---|---|----V---+
 248         |                 |   |   \---/    |   | <--- Add tunnel, ESP header etc
 249         |     NIC PMD     |   |   INLINE   |   |      header to packet.Packet
 250         |                 |   | CRYPTO PMD |   |      Encryption/Decryption and
 251         +--------|--------+   +----------------+      Authentication happens
 252                  |                                    inline.
 253         +--------|--------+
 254         |       NIC       |
 255         +--------|--------+
 256                  V
 257
 258 PDCP Flow Diagram
 259 ~~~~~~~~~~~~~~~~~
 260
 261 Based on 3GPP TS 36.323 Evolved Universal Terrestrial Radio Access (E-UTRA);
 262 Packet Data Convergence Protocol (PDCP) specification
 263
 264 .. code-block:: c
 265
 266         Transmitting PDCP Entity          Receiving PDCP Entity
 267                   |                                   ^
 268                   |                       +-----------|-----------+
 269                   V                       | In order delivery and |
 270         +---------|----------+            | Duplicate detection   |
 271         | Sequence Numbering |            |  (Data Plane only)    |
 272         +---------|----------+            +-----------|-----------+
 273                   |                                   |
 274         +---------|----------+            +-----------|----------+
 275         | Header Compression*|            | Header Decompression*|
 276         | (Data-Plane only)  |            |   (Data Plane only)  |
 277         +---------|----------+            +-----------|----------+
 278                   |                                   |
 279         +---------|-----------+           +-----------|----------+
 280         | Integrity Protection|           |Integrity Verification|
 281         | (Control Plane only)|           | (Control Plane only) |
 282         +---------|-----------+           +-----------|----------+
 283         +---------|-----------+            +----------|----------+
 284         |     Ciphering       |            |     Deciphering     |
 285         +---------|-----------+            +----------|----------+
 286         +---------|-----------+            +----------|----------+
 287         |   Add PDCP header   |            | Remove PDCP Header  |
 288         +---------|-----------+            +----------|----------+
 289                   |                                   |
 290                   +----------------->>----------------+
 291
 292
 293 .. note::
 294
 295     * Header Compression and decompression are not supported currently.
 296
 297 Just like IPsec, in case of PDCP also header addition/deletion, cipher/
 298 de-cipher, integrity protection/verification is done based on the action
 299 type chosen.
 300
 301 DOCSIS Protocol
 302 ~~~~~~~~~~~~~~~
 303
 304 The Data Over Cable Service Interface Specification (DOCSIS) support comprises
 305 the combination of encryption/decryption and CRC generation/verification, for
 306 use in a DOCSIS-MAC pipeline.
 307
 308 .. code-block:: c
 309
 310
 311                Downlink                       Uplink
 312                --------                       ------
 313
 314             Ethernet frame                Ethernet frame
 315            from core network              to core network
 316                   |                              ^
 317                   ~                              |
 318                   |                              ~         ----+
 319                   V                              |             |
 320         +---------|----------+        +----------|---------+   |
 321         |   CRC generation   |        |  CRC verification  |   |
 322         +---------|----------+        +----------|---------+   |   combined
 323                   |                              |             > Crypto + CRC
 324         +---------|----------+        +----------|---------+   |
 325         |     Encryption     |        |     Decryption     |   |
 326         +---------|----------+        +----------|---------+   |
 327                   |                              ^             |
 328                   ~                              |         ----+
 329                   |                              ~
 330                   V                              |
 331              DOCSIS frame                  DOCSIS frame
 332             to Cable Modem               from Cable Modem
 333
 334 The encryption/decryption is a combination of CBC and CFB modes using either AES
 335 or DES algorithms as specified in the DOCSIS Security Specification (from DPDK
 336 lib_rtecryptodev perspective, these are RTE_CRYPTO_CIPHER_AES_DOCSISBPI and
 337 RTE_CRYPTO_CIPHER_DES_DOCSISBPI).
 338
 339 The CRC is Ethernet CRC-32 as specified in Ethernet/[ISO/IEC 8802-3].
 340
 341 .. note::
 342
 343     * The offset and length of data for which CRC needs to be computed are
 344       specified via the auth offset and length fields of the rte_crypto_sym_op.
 345     * Other DOCSIS protocol functionality such as Header Checksum (HCS)
 346       calculation may be added in the future.
 347
 348 Device Features and Capabilities
 349 ---------------------------------
 350
 351 Device Capabilities For Security Operations
 352 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 353
 354 The device (crypto or ethernet) capabilities which support security operations,
 355 are defined by the security action type, security protocol, protocol
 356 capabilities and corresponding crypto capabilities for security. For the full
 357 scope of the Security capability see definition of rte_security_capability
 358 structure in the *DPDK API Reference*.
 359
 360 .. code-block:: c
 361
 362    struct rte_security_capability;
 363
 364 Each driver (crypto or ethernet) defines its own private array of capabilities
 365 for the operations it supports. Below is an example of the capabilities for a
 366 PMD which supports the IPsec and PDCP protocol.
 367
 368 .. code-block:: c
 369
 370     static const struct rte_security_capability pmd_security_capabilities[] = {
 371         { /* IPsec Lookaside Protocol offload ESP Tunnel Egress */
 372                 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL,
 373                 .protocol = RTE_SECURITY_PROTOCOL_IPSEC,
 374                 .ipsec = {
 375                         .proto = RTE_SECURITY_IPSEC_SA_PROTO_ESP,
 376                         .mode = RTE_SECURITY_IPSEC_SA_MODE_TUNNEL,
 377                         .direction = RTE_SECURITY_IPSEC_SA_DIR_EGRESS,
 378                         .options = { 0 }
 379                 },
 380                 .crypto_capabilities = pmd_capabilities
 381         },
 382         { /* IPsec Lookaside Protocol offload ESP Tunnel Ingress */
 383                 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL,
 384                 .protocol = RTE_SECURITY_PROTOCOL_IPSEC,
 385                 .ipsec = {
 386                         .proto = RTE_SECURITY_IPSEC_SA_PROTO_ESP,
 387                         .mode = RTE_SECURITY_IPSEC_SA_MODE_TUNNEL,
 388                         .direction = RTE_SECURITY_IPSEC_SA_DIR_INGRESS,
 389                         .options = { 0 }
 390                 },
 391                 .crypto_capabilities = pmd_capabilities
 392         },
 393         { /* PDCP Lookaside Protocol offload Data Plane */
 394                 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL,
 395                 .protocol = RTE_SECURITY_PROTOCOL_PDCP,
 396                 .pdcp = {
 397                         .domain = RTE_SECURITY_PDCP_MODE_DATA,
 398                         .capa_flags = 0
 399                 },
 400                 .crypto_capabilities = pmd_capabilities
 401         },
 402         { /* PDCP Lookaside Protocol offload Control */
 403                 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL,
 404                 .protocol = RTE_SECURITY_PROTOCOL_PDCP,
 405                 .pdcp = {
 406                         .domain = RTE_SECURITY_PDCP_MODE_CONTROL,
 407                         .capa_flags = 0
 408                 },
 409                 .crypto_capabilities = pmd_capabilities
 410         },
 411         {
 412                 .action = RTE_SECURITY_ACTION_TYPE_NONE
 413         }
 414     };
 415     static const struct rte_cryptodev_capabilities pmd_capabilities[] = {
 416         {    /* SHA1 HMAC */
 417             .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
 418             .sym = {
 419                 .xform_type = RTE_CRYPTO_SYM_XFORM_AUTH,
 420                 .auth = {
 421                     .algo = RTE_CRYPTO_AUTH_SHA1_HMAC,
 422                     .block_size = 64,
 423                     .key_size = {
 424                         .min = 64,
 425                         .max = 64,
 426                         .increment = 0
 427                     },
 428                     .digest_size = {
 429                         .min = 12,
 430                         .max = 12,
 431                         .increment = 0
 432                     },
 433                     .aad_size = { 0 },
 434                     .iv_size = { 0 }
 435                 }
 436             }
 437         },
 438         {    /* AES CBC */
 439             .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
 440             .sym = {
 441                 .xform_type = RTE_CRYPTO_SYM_XFORM_CIPHER,
 442                 .cipher = {
 443                     .algo = RTE_CRYPTO_CIPHER_AES_CBC,
 444                     .block_size = 16,
 445                     .key_size = {
 446                         .min = 16,
 447                         .max = 32,
 448                         .increment = 8
 449                     },
 450                     .iv_size = {
 451                         .min = 16,
 452                         .max = 16,
 453                         .increment = 0
 454                     }
 455                 }
 456             }
 457         }
 458     }
 459
 460 Below is an example of the capabilities for a PMD which supports the DOCSIS
 461 protocol.
 462
 463 .. code-block:: c
 464
 465     static const struct rte_security_capability pmd_security_capabilities[] = {
 466         { /* DOCSIS Uplink */
 467                 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL,
 468                 .protocol = RTE_SECURITY_PROTOCOL_DOCSIS,
 469                 .docsis = {
 470                         .direction = RTE_SECURITY_DOCSIS_UPLINK
 471                 },
 472                 .crypto_capabilities = pmd_capabilities
 473         },
 474         { /* DOCSIS Downlink */
 475                 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL,
 476                 .protocol = RTE_SECURITY_PROTOCOL_DOCSIS,
 477                 .docsis = {
 478                         .direction = RTE_SECURITY_DOCSIS_DOWNLINK
 479                 },
 480                 .crypto_capabilities = pmd_capabilities
 481         },
 482         {
 483                 .action = RTE_SECURITY_ACTION_TYPE_NONE
 484         }
 485     };
 486     static const struct rte_cryptodev_capabilities pmd_capabilities[] = {
 487         {    /* AES DOCSIS BPI */
 488             .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
 489             .sym = {
 490                 .xform_type = RTE_CRYPTO_SYM_XFORM_CIPHER,
 491                 .cipher = {
 492                     .algo = RTE_CRYPTO_CIPHER_AES_DOCSISBPI,
 493                     .block_size = 16,
 494                     .key_size = {
 495                         .min = 16,
 496                         .max = 32,
 497                         .increment = 16
 498                     },
 499                     .iv_size = {
 500                         .min = 16,
 501                         .max = 16,
 502                         .increment = 0
 503                     }
 504                 }
 505             }
 506         },
 507
 508         RTE_CRYPTODEV_END_OF_CAPABILITIES_LIST()
 509     };
 510
 511 Capabilities Discovery
 512 ~~~~~~~~~~~~~~~~~~~~~~
 513
 514 Discovering the features and capabilities of a driver (crypto/ethernet)
 515 is achieved through the ``rte_security_capabilities_get()`` function.
 516
 517 .. code-block:: c
 518
 519    const struct rte_security_capability *rte_security_capabilities_get(uint16_t id);
 520
 521 This allows the user to query a specific driver and get all device
 522 security capabilities. It returns an array of ``rte_security_capability`` structures
 523 which contains all the capabilities for that device.
 524
 525 Security Session Create/Free
 526 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 527
 528 Security Sessions are created to store the immutable fields of a particular Security
 529 Association for a particular protocol which is defined by a security session
 530 configuration structure which is used in the operation processing of a packet flow.
 531 Sessions are used to manage protocol specific information as well as crypto parameters.
 532 Security sessions cache this immutable data in a optimal way for the underlying PMD
 533 and this allows further acceleration of the offload of Crypto workloads.
 534
 535 The Security framework provides APIs to create and free sessions for crypto/ethernet
 536 devices, where sessions are mempool objects. It is the application's responsibility
 537 to create and manage two session mempools - one for session and other for session
 538 private data. The private session data mempool object size should be able to
 539 accommodate the driver's private data of security session. The application can get
 540 the size of session private data using API ``rte_security_session_get_size``.
 541 And the session mempool object size should be enough to accommodate
 542 ``rte_security_session``.
 543
 544 Once the session mempools have been created, ``rte_security_session_create()``
 545 is used to allocate and initialize a session for the required crypto/ethernet device.
 546
 547 Session APIs need a parameter ``rte_security_ctx`` to identify the crypto/ethernet
 548 security ops. This parameter can be retrieved using the APIs
 549 ``rte_cryptodev_get_sec_ctx()`` (for crypto device) or ``rte_eth_dev_get_sec_ctx``
 550 (for ethernet port).
 551
 552 Sessions already created can be updated with ``rte_security_session_update()``.
 553
 554 When a session is no longer used, the user must call ``rte_security_session_destroy()``
 555 to free the driver private session data and return the memory back to the mempool.
 556
 557 For look aside protocol offload to hardware crypto device, the ``rte_crypto_op``
 558 created by the application is attached to the security session by the API
 559 ``rte_security_attach_session()``.
 560
 561 For Inline Crypto and Inline protocol offload, device specific defined metadata is
 562 updated in the mbuf using ``rte_security_set_pkt_metadata()`` if
 563 ``DEV_TX_OFFLOAD_SEC_NEED_MDATA`` is set.
 564
 565 For inline protocol offloaded ingress traffic, the application can register a
 566 pointer, ``userdata`` , in the security session. When the packet is received,
 567 ``rte_security_get_userdata()`` would return the userdata registered for the
 568 security session which processed the packet.
 569
 570 .. note::
 571
 572     In case of inline processed packets, ``RTE_SECURITY_DYNFIELD_NAME`` field
 573     would be used by the driver to relay information on the security processing
 574     associated with the packet. In ingress, the driver would set this in Rx
 575     path while in egress, ``rte_security_set_pkt_metadata()`` would perform a
 576     similar operation. The application is expected not to modify the field
 577     when it has relevant info. For ingress, this device-specific 64 bit value
 578     is required to derive other information (like userdata), required for
 579     identifying the security processing done on the packet.
 580
 581 Security session configuration
 582 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 583
 584 Security Session configuration structure is defined as ``rte_security_session_conf``
 585
 586 .. code-block:: c
 587
 588     struct rte_security_session_conf {
 589         enum rte_security_session_action_type action_type;
 590         /**< Type of action to be performed on the session */
 591         enum rte_security_session_protocol protocol;
 592         /**< Security protocol to be configured */
 593         union {
 594                 struct rte_security_ipsec_xform ipsec;
 595                 struct rte_security_macsec_xform macsec;
 596                 struct rte_security_pdcp_xform pdcp;
 597                 struct rte_security_docsis_xform docsis;
 598         };
 599         /**< Configuration parameters for security session */
 600         struct rte_crypto_sym_xform *crypto_xform;
 601         /**< Security Session Crypto Transformations */
 602         void *userdata;
 603         /**< Application specific userdata to be saved with session */
 604     };
 605
 606 The configuration structure reuses the ``rte_crypto_sym_xform`` struct for crypto related
 607 configuration. The ``rte_security_session_action_type`` struct is used to specify whether the
 608 session is configured for Lookaside Protocol offload or Inline Crypto or Inline Protocol
 609 Offload.
 610
 611 .. code-block:: c
 612
 613     enum rte_security_session_action_type {
 614         RTE_SECURITY_ACTION_TYPE_NONE,
 615         /**< No security actions */
 616         RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO,
 617         /**< Crypto processing for security protocol is processed inline
 618          * during transmission
 619          */
 620         RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL,
 621         /**< All security protocol processing is performed inline during
 622          * transmission
 623          */
 624         RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL,
 625         /**< All security protocol processing including crypto is performed
 626          * on a lookaside accelerator
 627          */
 628         RTE_SECURITY_ACTION_TYPE_CPU_CRYPTO
 629         /**< Similar to ACTION_TYPE_NONE but crypto processing for security
 630          * protocol is processed synchronously by a CPU.
 631          */
 632     };
 633
 634 The ``rte_security_session_protocol`` is defined as
 635
 636 .. code-block:: c
 637
 638     enum rte_security_session_protocol {
 639         RTE_SECURITY_PROTOCOL_IPSEC = 1,
 640         /**< IPsec Protocol */
 641         RTE_SECURITY_PROTOCOL_MACSEC,
 642         /**< MACSec Protocol */
 643         RTE_SECURITY_PROTOCOL_PDCP,
 644         /**< PDCP Protocol */
 645         RTE_SECURITY_PROTOCOL_DOCSIS,
 646         /**< DOCSIS Protocol */
 647     };
 648
 649 Currently the library defines configuration parameters for IPsec and PDCP only.
 650 For other protocols like MACSec, structures and enums are defined as place holders
 651 which will be updated in the future.
 652
 653 IPsec related configuration parameters are defined in ``rte_security_ipsec_xform``
 654
 655 PDCP related configuration parameters are defined in ``rte_security_pdcp_xform``
 656
 657 DOCSIS related configuration parameters are defined in ``rte_security_docsis_xform``
 658
 659
 660 Security API
 661 ~~~~~~~~~~~~
 662
 663 The rte_security Library API is described in the *DPDK API Reference* document.
 664
 665 Flow based Security Session
 666 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 667
 668 In the case of NIC based offloads, the security session specified in the
 669 'rte_flow_action_security' must be created on the same port as the
 670 flow action that is being specified.
 671
 672 The ingress/egress flow attribute should match that specified in the security
 673 session if the security session supports the definition of the direction.
 674
 675 Multiple flows can be configured to use the same security session. For
 676 example if the security session specifies an egress IPsec SA, then multiple
 677 flows can be specified to that SA. In the case of an ingress IPsec SA then
 678 it is only valid to have a single flow to map to that security session.
 679
 680 .. code-block:: console
 681
 682          Configuration Path
 683                  |
 684         +--------|--------+
 685         |    Add/Remove   |
 686         |     IPsec SA    |   <------ Build security flow action of
 687         |        |        |           ipsec transform
 688         |--------|--------|
 689                  |
 690         +--------V--------+
 691         |   Flow API      |
 692         +--------|--------+
 693                  |
 694         +--------V--------+
 695         |                 |
 696         |     NIC PMD     |   <------ Add/Remove SA to/from hw context
 697         |                 |
 698         +--------|--------+
 699                  |
 700         +--------|--------+
 701         |  HW ACCELERATED |
 702         |        NIC      |
 703         |                 |
 704         +--------|--------+
 705
 706 * Add/Delete SA flow:
 707   To add a new inline SA construct a rte_flow_item for Ethernet + IP + ESP
 708   using the SA selectors and the ``rte_crypto_ipsec_xform`` as the ``rte_flow_action``.
 709   Note that any rte_flow_items may be empty, which means it is not checked.
 710
 711 .. code-block:: console
 712
 713     In its most basic form, IPsec flow specification is as follows:
 714         +-------+     +----------+    +--------+    +-----+
 715         |  Eth  | ->  |   IP4/6  | -> |   ESP  | -> | END |
 716         +-------+     +----------+    +--------+    +-----+
 717
 718     However, the API can represent, IPsec crypto offload with any encapsulation:
 719         +-------+            +--------+    +-----+
 720         |  Eth  | ->  ... -> |   ESP  | -> | END |
 721         +-------+            +--------+    +-----+