app/testpmd: add flow table management
[dpdk.git] / doc / guides / prog_guide / rte_security.rst
1 ..  SPDX-License-Identifier: BSD-3-Clause
2     Copyright 2017,2020-2021 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         { /* PDCP Lookaside Protocol offload short MAC-I */
412                 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL,
413                 .protocol = RTE_SECURITY_PROTOCOL_PDCP,
414                 .pdcp = {
415                         .domain = RTE_SECURITY_PDCP_MODE_SHORT_MAC,
416                         .capa_flags = 0
417                 },
418                 .crypto_capabilities = pmd_capabilities
419         },
420         {
421                 .action = RTE_SECURITY_ACTION_TYPE_NONE
422         }
423     };
424     static const struct rte_cryptodev_capabilities pmd_capabilities[] = {
425         {    /* SHA1 HMAC */
426             .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
427             .sym = {
428                 .xform_type = RTE_CRYPTO_SYM_XFORM_AUTH,
429                 .auth = {
430                     .algo = RTE_CRYPTO_AUTH_SHA1_HMAC,
431                     .block_size = 64,
432                     .key_size = {
433                         .min = 64,
434                         .max = 64,
435                         .increment = 0
436                     },
437                     .digest_size = {
438                         .min = 12,
439                         .max = 12,
440                         .increment = 0
441                     },
442                     .aad_size = { 0 },
443                     .iv_size = { 0 }
444                 }
445             }
446         },
447         {    /* AES CBC */
448             .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
449             .sym = {
450                 .xform_type = RTE_CRYPTO_SYM_XFORM_CIPHER,
451                 .cipher = {
452                     .algo = RTE_CRYPTO_CIPHER_AES_CBC,
453                     .block_size = 16,
454                     .key_size = {
455                         .min = 16,
456                         .max = 32,
457                         .increment = 8
458                     },
459                     .iv_size = {
460                         .min = 16,
461                         .max = 16,
462                         .increment = 0
463                     }
464                 }
465             }
466         }
467     }
468
469 Below is an example of the capabilities for a PMD which supports the DOCSIS
470 protocol.
471
472 .. code-block:: c
473
474     static const struct rte_security_capability pmd_security_capabilities[] = {
475         { /* DOCSIS Uplink */
476                 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL,
477                 .protocol = RTE_SECURITY_PROTOCOL_DOCSIS,
478                 .docsis = {
479                         .direction = RTE_SECURITY_DOCSIS_UPLINK
480                 },
481                 .crypto_capabilities = pmd_capabilities
482         },
483         { /* DOCSIS Downlink */
484                 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL,
485                 .protocol = RTE_SECURITY_PROTOCOL_DOCSIS,
486                 .docsis = {
487                         .direction = RTE_SECURITY_DOCSIS_DOWNLINK
488                 },
489                 .crypto_capabilities = pmd_capabilities
490         },
491         {
492                 .action = RTE_SECURITY_ACTION_TYPE_NONE
493         }
494     };
495     static const struct rte_cryptodev_capabilities pmd_capabilities[] = {
496         {    /* AES DOCSIS BPI */
497             .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
498             .sym = {
499                 .xform_type = RTE_CRYPTO_SYM_XFORM_CIPHER,
500                 .cipher = {
501                     .algo = RTE_CRYPTO_CIPHER_AES_DOCSISBPI,
502                     .block_size = 16,
503                     .key_size = {
504                         .min = 16,
505                         .max = 32,
506                         .increment = 16
507                     },
508                     .iv_size = {
509                         .min = 16,
510                         .max = 16,
511                         .increment = 0
512                     }
513                 }
514             }
515         },
516
517         RTE_CRYPTODEV_END_OF_CAPABILITIES_LIST()
518     };
519
520 Capabilities Discovery
521 ~~~~~~~~~~~~~~~~~~~~~~
522
523 Discovering the features and capabilities of a driver (crypto/ethernet)
524 is achieved through the ``rte_security_capabilities_get()`` function.
525
526 .. code-block:: c
527
528    const struct rte_security_capability *rte_security_capabilities_get(uint16_t id);
529
530 This allows the user to query a specific driver and get all device
531 security capabilities. It returns an array of ``rte_security_capability`` structures
532 which contains all the capabilities for that device.
533
534 Security Session Create/Free
535 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
536
537 Security Sessions are created to store the immutable fields of a particular Security
538 Association for a particular protocol which is defined by a security session
539 configuration structure which is used in the operation processing of a packet flow.
540 Sessions are used to manage protocol specific information as well as crypto parameters.
541 Security sessions cache this immutable data in a optimal way for the underlying PMD
542 and this allows further acceleration of the offload of Crypto workloads.
543
544 The Security framework provides APIs to create and free sessions for crypto/ethernet
545 devices, where sessions are mempool objects. It is the application's responsibility
546 to create and manage two session mempools - one for session and other for session
547 private data. The private session data mempool object size should be able to
548 accommodate the driver's private data of security session. The application can get
549 the size of session private data using API ``rte_security_session_get_size``.
550 And the session mempool object size should be enough to accommodate
551 ``rte_security_session``.
552
553 Once the session mempools have been created, ``rte_security_session_create()``
554 is used to allocate and initialize a session for the required crypto/ethernet device.
555
556 Session APIs need a parameter ``rte_security_ctx`` to identify the crypto/ethernet
557 security ops. This parameter can be retrieved using the APIs
558 ``rte_cryptodev_get_sec_ctx()`` (for crypto device) or ``rte_eth_dev_get_sec_ctx``
559 (for ethernet port).
560
561 Sessions already created can be updated with ``rte_security_session_update()``.
562
563 When a session is no longer used, the user must call ``rte_security_session_destroy()``
564 to free the driver private session data and return the memory back to the mempool.
565
566 For look aside protocol offload to hardware crypto device, the ``rte_crypto_op``
567 created by the application is attached to the security session by the API
568 ``rte_security_attach_session()``.
569
570 For Inline Crypto and Inline protocol offload, device specific defined metadata is
571 updated in the mbuf using ``rte_security_set_pkt_metadata()`` if
572 ``RTE_ETH_TX_OFFLOAD_SEC_NEED_MDATA`` is set.
573
574 For inline protocol offloaded ingress traffic, the application can register a
575 pointer, ``userdata`` , in the security session. When the packet is received,
576 ``rte_security_get_userdata()`` would return the userdata registered for the
577 security session which processed the packet.
578
579 .. note::
580
581     In case of inline processed packets, ``RTE_SECURITY_DYNFIELD_NAME`` field
582     would be used by the driver to relay information on the security processing
583     associated with the packet. In ingress, the driver would set this in Rx
584     path while in egress, ``rte_security_set_pkt_metadata()`` would perform a
585     similar operation. The application is expected not to modify the field
586     when it has relevant info. For ingress, this device-specific 64 bit value
587     is required to derive other information (like userdata), required for
588     identifying the security processing done on the packet.
589
590 Security session configuration
591 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
592
593 Security Session configuration structure is defined as ``rte_security_session_conf``
594
595 .. code-block:: c
596
597     struct rte_security_session_conf {
598         enum rte_security_session_action_type action_type;
599         /**< Type of action to be performed on the session */
600         enum rte_security_session_protocol protocol;
601         /**< Security protocol to be configured */
602         union {
603                 struct rte_security_ipsec_xform ipsec;
604                 struct rte_security_macsec_xform macsec;
605                 struct rte_security_pdcp_xform pdcp;
606                 struct rte_security_docsis_xform docsis;
607         };
608         /**< Configuration parameters for security session */
609         struct rte_crypto_sym_xform *crypto_xform;
610         /**< Security Session Crypto Transformations */
611         void *userdata;
612         /**< Application specific userdata to be saved with session */
613     };
614
615 The configuration structure reuses the ``rte_crypto_sym_xform`` struct for crypto related
616 configuration. The ``rte_security_session_action_type`` struct is used to specify whether the
617 session is configured for Lookaside Protocol offload or Inline Crypto or Inline Protocol
618 Offload.
619
620 .. code-block:: c
621
622     enum rte_security_session_action_type {
623         RTE_SECURITY_ACTION_TYPE_NONE,
624         /**< No security actions */
625         RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO,
626         /**< Crypto processing for security protocol is processed inline
627          * during transmission
628          */
629         RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL,
630         /**< All security protocol processing is performed inline during
631          * transmission
632          */
633         RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL,
634         /**< All security protocol processing including crypto is performed
635          * on a lookaside accelerator
636          */
637         RTE_SECURITY_ACTION_TYPE_CPU_CRYPTO
638         /**< Similar to ACTION_TYPE_NONE but crypto processing for security
639          * protocol is processed synchronously by a CPU.
640          */
641     };
642
643 The ``rte_security_session_protocol`` is defined as
644
645 .. code-block:: c
646
647     enum rte_security_session_protocol {
648         RTE_SECURITY_PROTOCOL_IPSEC = 1,
649         /**< IPsec Protocol */
650         RTE_SECURITY_PROTOCOL_MACSEC,
651         /**< MACSec Protocol */
652         RTE_SECURITY_PROTOCOL_PDCP,
653         /**< PDCP Protocol */
654         RTE_SECURITY_PROTOCOL_DOCSIS,
655         /**< DOCSIS Protocol */
656     };
657
658 Currently the library defines configuration parameters for IPsec and PDCP only.
659 For other protocols like MACSec, structures and enums are defined as place holders
660 which will be updated in the future.
661
662 IPsec related configuration parameters are defined in ``rte_security_ipsec_xform``
663
664 PDCP related configuration parameters are defined in ``rte_security_pdcp_xform``
665
666 DOCSIS related configuration parameters are defined in ``rte_security_docsis_xform``
667
668
669 Security API
670 ~~~~~~~~~~~~
671
672 The rte_security Library API is described in the *DPDK API Reference* document.
673
674 Flow based Security Session
675 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
676
677 In the case of NIC based offloads, the security session specified in the
678 'rte_flow_action_security' must be created on the same port as the
679 flow action that is being specified.
680
681 The ingress/egress flow attribute should match that specified in the security
682 session if the security session supports the definition of the direction.
683
684 Multiple flows can be configured to use the same security session. For
685 example if the security session specifies an egress IPsec SA, then multiple
686 flows can be specified to that SA. In the case of an ingress IPsec SA then
687 it is only valid to have a single flow to map to that security session.
688
689 .. code-block:: console
690
691          Configuration Path
692                  |
693         +--------|--------+
694         |    Add/Remove   |
695         |     IPsec SA    |   <------ Build security flow action of
696         |        |        |           ipsec transform
697         |--------|--------|
698                  |
699         +--------V--------+
700         |   Flow API      |
701         +--------|--------+
702                  |
703         +--------V--------+
704         |                 |
705         |     NIC PMD     |   <------ Add/Remove SA to/from hw context
706         |                 |
707         +--------|--------+
708                  |
709         +--------|--------+
710         |  HW ACCELERATED |
711         |        NIC      |
712         |                 |
713         +--------|--------+
714
715 * Add/Delete SA flow:
716   To add a new inline SA construct a rte_flow_item for Ethernet + IP + ESP
717   using the SA selectors and the ``rte_crypto_ipsec_xform`` as the ``rte_flow_action``.
718   Note that any rte_flow_items may be empty, which means it is not checked.
719
720 .. code-block:: console
721
722     In its most basic form, IPsec flow specification is as follows:
723         +-------+     +----------+    +--------+    +-----+
724         |  Eth  | ->  |   IP4/6  | -> |   ESP  | -> | END |
725         +-------+     +----------+    +--------+    +-----+
726
727     However, the API can represent, IPsec crypto offload with any encapsulation:
728         +-------+            +--------+    +-----+
729         |  Eth  | ->  ... -> |   ESP  | -> | END |
730         +-------+            +--------+    +-----+
731
732
733 Telemetry support
734 -----------------
735
736 The Security library has support for displaying Crypto device information
737 with respect to its Security capabilities. Telemetry commands that can be used
738 are shown below.
739
740 #. Get the list of available Crypto devices by ID, that supports Security features::
741
742      --> /security/cryptodev/list
743      {"/security/cryptodev/list": [0, 1, 2, 3]}
744
745 #. Get the security capabilities of a Crypto device::
746
747      --> /security/cryptodev/sec_caps,0
748          {"/security/cryptodev/sec_caps": {"sec_caps": [<array of serialized bytes of
749          capabilities>], "sec_caps_n": <number of capabilities>}}
750
751  #. Get the security crypto capabilities of a Crypto device::
752
753      --> /security/cryptodev/crypto_caps,0,0
754          {"/security/cryptodev/crypto_caps": {"crypto_caps": [<array of serialized bytes of
755          capabilities>], "crypto_caps_n": <number of capabilities>}}
756
757 For more information on how to use the Telemetry interface, see
758 the :doc:`../howto/telemetry`.