1 .. SPDX-License-Identifier: BSD-3-Clause
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
20 The security library provides an additional offload capability to an existing
21 crypto device and/or ethernet device.
23 .. code-block:: console
29 +-----------+ +--------------+
30 | NIC PMD | | CRYPTO PMD |
31 +-----------+ +--------------+
35 Currently, the security library does not support the case of multi-process.
36 It will be updated in the future releases.
38 The supported offload types are explained in the sections below.
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.
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.
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.
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
73 The underlying device may support post encryption TSO.
75 .. code-block:: console
86 | | Tunnel | | <------ Add tunnel header to packet
89 | | ESP | | <------ Add ESP header without trailer to packet
90 | | | | <------ Mark packet to be offloaded, add trailer
91 | +------|------+ | meta-data to mbuf
100 | NIC PMD | <------ Set hw context for inline crypto offload
105 | HW ACCELERATED | <------ Packet Encryption and
106 | NIC | Authentication happens inline
111 Inline protocol offload
112 ~~~~~~~~~~~~~~~~~~~~~~~
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.
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_mbuf.udata64`` field. This will allow the application
129 to identify the security processing done on the packet.
133 The underlying device in this case is stateful. It is expected that
134 the device shall support crypto processing for all kind of packets matching
135 to a given flow, this includes fragmented packets (post reassembly).
136 E.g. in case of IPsec the device may internally manage anti-replay etc.
137 It will provide a configuration option for anti-replay behavior i.e. to drop
138 the packets or pass them to driver with error flags set in the descriptor.
140 Egress Data path - The software will send the plain packet without any
141 security protocol headers added to the packet. The driver will configure
142 the security index and other requirement in tx descriptors.
143 The hardware device will do security processing on the packet that includes
144 adding the relevant protocol headers and encrypting the data before sending
145 the packet out. The software should make sure that the buffer
146 has required head room and tail room for any protocol header addition. The
147 software may also do early fragmentation if the resultant packet is expected
148 to cross the MTU size.
153 The underlying device will manage state information required for egress
154 processing. E.g. in case of IPsec, the seq number will be added to the
155 packet, however the device shall provide indication when the sequence number
156 is about to overflow. The underlying device may support post encryption TSO.
158 .. code-block:: console
169 | | Desc | | <------ Mark packet to be offloaded
179 | NIC PMD | <------ Set hw context for inline crypto offload
184 | HW ACCELERATED | <------ Add tunnel, ESP header etc header to
185 | NIC | packet. Packet Encryption and
186 | | Authentication happens inline.
190 Lookaside protocol offload
191 ~~~~~~~~~~~~~~~~~~~~~~~~~~
193 RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL:
194 This extends librte_cryptodev to support the programming of IPsec
195 Security Association (SA) as part of a crypto session creation including
196 the definition. In addition to standard crypto processing, as defined by
197 the cryptodev, the security protocol processing is also offloaded to the
200 Decryption: The packet is sent to the crypto device for security
201 protocol processing. The device will decrypt the packet and it will also
202 optionally remove additional security headers from the packet.
203 E.g. in case of IPsec, IPsec tunnel headers (if any), ESP/AH headers
204 will be removed from the packet and the decrypted packet may contain
209 In case of IPsec the device may internally manage anti-replay etc.
210 It will provide a configuration option for anti-replay behavior i.e. to drop
211 the packets or pass them to driver with error flags set in descriptor.
213 Encryption: The software will submit the packet to cryptodev as usual
214 for encryption, the hardware device in this case will also add the relevant
215 security protocol header along with encrypting the packet. The software
216 should make sure that the buffer has required head room and tail room
217 for any protocol header addition.
221 In the case of IPsec, the seq number will be added to the packet,
222 It shall provide an indication when the sequence number is about to
225 .. code-block:: console
233 | | SADB lookup | | <------ SA maps to cryptodev session
236 | | \--------------------\
237 | | Crypto | | | <- Crypto processing through
238 | | /----------------\ | inline crypto PMD
239 | +------|------+ | | |
240 +--------V--------+ | |
242 +--------V--------+ | | create <-- SA is added to hw
243 | L2 Stack | | | inline using existing create
244 +--------|--------+ | | session sym session APIs
246 +--------V--------+ +---|---|----V---+
247 | | | \---/ | | <--- Add tunnel, ESP header etc
248 | NIC PMD | | INLINE | | header to packet.Packet
249 | | | CRYPTO PMD | | Encryption/Decryption and
250 +--------|--------+ +----------------+ Authentication happens
260 Based on 3GPP TS 36.323 Evolved Universal Terrestrial Radio Access (E-UTRA);
261 Packet Data Convergence Protocol (PDCP) specification
265 Transmitting PDCP Entity Receiving PDCP Entity
267 | +-----------|-----------+
268 V | In order delivery and |
269 +---------|----------+ | Duplicate detection |
270 | Sequence Numbering | | (Data Plane only) |
271 +---------|----------+ +-----------|-----------+
273 +---------|----------+ +-----------|----------+
274 | Header Compression*| | Header Decompression*|
275 | (Data-Plane only) | | (Data Plane only) |
276 +---------|----------+ +-----------|----------+
278 +---------|-----------+ +-----------|----------+
279 | Integrity Protection| |Integrity Verification|
280 | (Control Plane only)| | (Control Plane only) |
281 +---------|-----------+ +-----------|----------+
282 +---------|-----------+ +----------|----------+
283 | Ciphering | | Deciphering |
284 +---------|-----------+ +----------|----------+
285 +---------|-----------+ +----------|----------+
286 | Add PDCP header | | Remove PDCP Header |
287 +---------|-----------+ +----------|----------+
289 +----------------->>----------------+
294 * Header Compression and decompression are not supported currently.
296 Just like IPsec, in case of PDCP also header addition/deletion, cipher/
297 de-cipher, integrity protection/verification is done based on the action
303 The Data Over Cable Service Interface Specification (DOCSIS) support comprises
304 the combination of encryption/decryption and CRC generation/verification, for
305 use in a DOCSIS-MAC pipeline.
313 Ethernet frame Ethernet frame
314 from core network to core network
319 +---------|----------+ +----------|---------+ |
320 | CRC generation | | CRC verification | |
321 +---------|----------+ +----------|---------+ | combined
323 +---------|----------+ +----------|---------+ |
324 | Encryption | | Decryption | |
325 +---------|----------+ +----------|---------+ |
330 DOCSIS frame DOCSIS frame
331 to Cable Modem from Cable Modem
333 The encryption/decryption is a combination of CBC and CFB modes using either AES
334 or DES algorithms as specified in the DOCSIS Security Specification (from DPDK
335 lib_rtecryptodev perspective, these are RTE_CRYPTO_CIPHER_AES_DOCSISBPI and
336 RTE_CRYPTO_CIPHER_DES_DOCSISBPI).
338 The CRC is Ethernet CRC-32 as specified in Ethernet/[ISO/IEC 8802-3].
342 * The offset and length of data for which CRC needs to be computed are
343 specified via the auth offset and length fields of the rte_crypto_sym_op.
344 * Other DOCSIS protocol functionality such as Header Checksum (HCS)
345 calculation may be added in the future.
347 Device Features and Capabilities
348 ---------------------------------
350 Device Capabilities For Security Operations
351 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
353 The device (crypto or ethernet) capabilities which support security operations,
354 are defined by the security action type, security protocol, protocol
355 capabilities and corresponding crypto capabilities for security. For the full
356 scope of the Security capability see definition of rte_security_capability
357 structure in the *DPDK API Reference*.
361 struct rte_security_capability;
363 Each driver (crypto or ethernet) defines its own private array of capabilities
364 for the operations it supports. Below is an example of the capabilities for a
365 PMD which supports the IPsec and PDCP protocol.
369 static const struct rte_security_capability pmd_security_capabilities[] = {
370 { /* IPsec Lookaside Protocol offload ESP Tunnel Egress */
371 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL,
372 .protocol = RTE_SECURITY_PROTOCOL_IPSEC,
374 .proto = RTE_SECURITY_IPSEC_SA_PROTO_ESP,
375 .mode = RTE_SECURITY_IPSEC_SA_MODE_TUNNEL,
376 .direction = RTE_SECURITY_IPSEC_SA_DIR_EGRESS,
379 .crypto_capabilities = pmd_capabilities
381 { /* IPsec Lookaside Protocol offload ESP Tunnel Ingress */
382 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL,
383 .protocol = RTE_SECURITY_PROTOCOL_IPSEC,
385 .proto = RTE_SECURITY_IPSEC_SA_PROTO_ESP,
386 .mode = RTE_SECURITY_IPSEC_SA_MODE_TUNNEL,
387 .direction = RTE_SECURITY_IPSEC_SA_DIR_INGRESS,
390 .crypto_capabilities = pmd_capabilities
392 { /* PDCP Lookaside Protocol offload Data Plane */
393 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL,
394 .protocol = RTE_SECURITY_PROTOCOL_PDCP,
396 .domain = RTE_SECURITY_PDCP_MODE_DATA,
399 .crypto_capabilities = pmd_capabilities
401 { /* PDCP Lookaside Protocol offload Control */
402 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL,
403 .protocol = RTE_SECURITY_PROTOCOL_PDCP,
405 .domain = RTE_SECURITY_PDCP_MODE_CONTROL,
408 .crypto_capabilities = pmd_capabilities
411 .action = RTE_SECURITY_ACTION_TYPE_NONE
414 static const struct rte_cryptodev_capabilities pmd_capabilities[] = {
416 .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
418 .xform_type = RTE_CRYPTO_SYM_XFORM_AUTH,
420 .algo = RTE_CRYPTO_AUTH_SHA1_HMAC,
438 .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
440 .xform_type = RTE_CRYPTO_SYM_XFORM_CIPHER,
442 .algo = RTE_CRYPTO_CIPHER_AES_CBC,
459 Below is an example of the capabilities for a PMD which supports the DOCSIS
464 static const struct rte_security_capability pmd_security_capabilities[] = {
465 { /* DOCSIS Uplink */
466 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL,
467 .protocol = RTE_SECURITY_PROTOCOL_DOCSIS,
469 .direction = RTE_SECURITY_DOCSIS_UPLINK
471 .crypto_capabilities = pmd_capabilities
473 { /* DOCSIS Downlink */
474 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL,
475 .protocol = RTE_SECURITY_PROTOCOL_DOCSIS,
477 .direction = RTE_SECURITY_DOCSIS_DOWNLINK
479 .crypto_capabilities = pmd_capabilities
482 .action = RTE_SECURITY_ACTION_TYPE_NONE
485 static const struct rte_cryptodev_capabilities pmd_capabilities[] = {
486 { /* AES DOCSIS BPI */
487 .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
489 .xform_type = RTE_CRYPTO_SYM_XFORM_CIPHER,
491 .algo = RTE_CRYPTO_CIPHER_AES_DOCSISBPI,
507 RTE_CRYPTODEV_END_OF_CAPABILITIES_LIST()
510 Capabilities Discovery
511 ~~~~~~~~~~~~~~~~~~~~~~
513 Discovering the features and capabilities of a driver (crypto/ethernet)
514 is achieved through the ``rte_security_capabilities_get()`` function.
518 const struct rte_security_capability *rte_security_capabilities_get(uint16_t id);
520 This allows the user to query a specific driver and get all device
521 security capabilities. It returns an array of ``rte_security_capability`` structures
522 which contains all the capabilities for that device.
524 Security Session Create/Free
525 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
527 Security Sessions are created to store the immutable fields of a particular Security
528 Association for a particular protocol which is defined by a security session
529 configuration structure which is used in the operation processing of a packet flow.
530 Sessions are used to manage protocol specific information as well as crypto parameters.
531 Security sessions cache this immutable data in a optimal way for the underlying PMD
532 and this allows further acceleration of the offload of Crypto workloads.
534 The Security framework provides APIs to create and free sessions for crypto/ethernet
535 devices, where sessions are mempool objects. It is the application's responsibility
536 to create and manage the session mempools. The mempool object size should be able to
537 accommodate the driver's private data of security session.
539 Once the session mempools have been created, ``rte_security_session_create()``
540 is used to allocate and initialize a session for the required crypto/ethernet device.
542 Session APIs need a parameter ``rte_security_ctx`` to identify the crypto/ethernet
543 security ops. This parameter can be retrieved using the APIs
544 ``rte_cryptodev_get_sec_ctx()`` (for crypto device) or ``rte_eth_dev_get_sec_ctx``
547 Sessions already created can be updated with ``rte_security_session_update()``.
549 When a session is no longer used, the user must call ``rte_security_session_destroy()``
550 to free the driver private session data and return the memory back to the mempool.
552 For look aside protocol offload to hardware crypto device, the ``rte_crypto_op``
553 created by the application is attached to the security session by the API
554 ``rte_security_attach_session()``.
556 For Inline Crypto and Inline protocol offload, device specific defined metadata is
557 updated in the mbuf using ``rte_security_set_pkt_metadata()`` if
558 ``DEV_TX_OFFLOAD_SEC_NEED_MDATA`` is set.
560 For inline protocol offloaded ingress traffic, the application can register a
561 pointer, ``userdata`` , in the security session. When the packet is received,
562 ``rte_security_get_userdata()`` would return the userdata registered for the
563 security session which processed the packet.
567 In case of inline processed packets, ``rte_mbuf.udata64`` field would be
568 used by the driver to relay information on the security processing
569 associated with the packet. In ingress, the driver would set this in Rx
570 path while in egress, ``rte_security_set_pkt_metadata()`` would perform a
571 similar operation. The application is expected not to modify the field
572 when it has relevant info. For ingress, this device-specific 64 bit value
573 is required to derive other information (like userdata), required for
574 identifying the security processing done on the packet.
576 Security session configuration
577 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
579 Security Session configuration structure is defined as ``rte_security_session_conf``
583 struct rte_security_session_conf {
584 enum rte_security_session_action_type action_type;
585 /**< Type of action to be performed on the session */
586 enum rte_security_session_protocol protocol;
587 /**< Security protocol to be configured */
589 struct rte_security_ipsec_xform ipsec;
590 struct rte_security_macsec_xform macsec;
591 struct rte_security_pdcp_xform pdcp;
592 struct rte_security_docsis_xform docsis;
594 /**< Configuration parameters for security session */
595 struct rte_crypto_sym_xform *crypto_xform;
596 /**< Security Session Crypto Transformations */
598 /**< Application specific userdata to be saved with session */
601 The configuration structure reuses the ``rte_crypto_sym_xform`` struct for crypto related
602 configuration. The ``rte_security_session_action_type`` struct is used to specify whether the
603 session is configured for Lookaside Protocol offload or Inline Crypto or Inline Protocol
608 enum rte_security_session_action_type {
609 RTE_SECURITY_ACTION_TYPE_NONE,
610 /**< No security actions */
611 RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO,
612 /**< Crypto processing for security protocol is processed inline
613 * during transmission
615 RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL,
616 /**< All security protocol processing is performed inline during
619 RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL,
620 /**< All security protocol processing including crypto is performed
621 * on a lookaside accelerator
623 RTE_SECURITY_ACTION_TYPE_CPU_CRYPTO
624 /**< Similar to ACTION_TYPE_NONE but crypto processing for security
625 * protocol is processed synchronously by a CPU.
629 The ``rte_security_session_protocol`` is defined as
633 enum rte_security_session_protocol {
634 RTE_SECURITY_PROTOCOL_IPSEC = 1,
635 /**< IPsec Protocol */
636 RTE_SECURITY_PROTOCOL_MACSEC,
637 /**< MACSec Protocol */
638 RTE_SECURITY_PROTOCOL_PDCP,
639 /**< PDCP Protocol */
640 RTE_SECURITY_PROTOCOL_DOCSIS,
641 /**< DOCSIS Protocol */
644 Currently the library defines configuration parameters for IPsec and PDCP only.
645 For other protocols like MACSec, structures and enums are defined as place holders
646 which will be updated in the future.
648 IPsec related configuration parameters are defined in ``rte_security_ipsec_xform``
652 struct rte_security_ipsec_xform {
654 /**< SA security parameter index */
657 struct rte_security_ipsec_sa_options options;
658 /**< various SA options */
659 enum rte_security_ipsec_sa_direction direction;
660 /**< IPsec SA Direction - Egress/Ingress */
661 enum rte_security_ipsec_sa_protocol proto;
662 /**< IPsec SA Protocol - AH/ESP */
663 enum rte_security_ipsec_sa_mode mode;
664 /**< IPsec SA Mode - transport/tunnel */
665 struct rte_security_ipsec_tunnel_param tunnel;
666 /**< Tunnel parameters, NULL for transport mode */
669 PDCP related configuration parameters are defined in ``rte_security_pdcp_xform``
673 struct rte_security_pdcp_xform {
674 int8_t bearer; /**< PDCP bearer ID */
675 /** Enable in order delivery, this field shall be set only if
676 * driver/HW is capable. See RTE_SECURITY_PDCP_ORDERING_CAP.
679 /** Notify driver/HW to detect and remove duplicate packets.
680 * This field should be set only when driver/hw is capable.
681 * See RTE_SECURITY_PDCP_DUP_DETECT_CAP.
683 uint8_t remove_duplicates;
684 /** PDCP mode of operation: Control or data */
685 enum rte_security_pdcp_domain domain;
686 /** PDCP Frame Direction 0:UL 1:DL */
687 enum rte_security_pdcp_direction pkt_dir;
688 /** Sequence number size, 5/7/12/15/18 */
689 enum rte_security_pdcp_sn_size sn_size;
690 /** Starting Hyper Frame Number to be used together with the SN
691 * from the PDCP frames
694 /** HFN Threshold for key renegotiation */
695 uint32_t hfn_threshold;
698 DOCSIS related configuration parameters are defined in ``rte_security_docsis_xform``
702 struct rte_security_docsis_xform {
703 enum rte_security_docsis_direction direction;
704 /**< DOCSIS direction */
711 The rte_security Library API is described in the *DPDK API Reference* document.
713 Flow based Security Session
714 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
716 In the case of NIC based offloads, the security session specified in the
717 'rte_flow_action_security' must be created on the same port as the
718 flow action that is being specified.
720 The ingress/egress flow attribute should match that specified in the security
721 session if the security session supports the definition of the direction.
723 Multiple flows can be configured to use the same security session. For
724 example if the security session specifies an egress IPsec SA, then multiple
725 flows can be specified to that SA. In the case of an ingress IPsec SA then
726 it is only valid to have a single flow to map to that security session.
728 .. code-block:: console
734 | IPsec SA | <------ Build security flow action of
735 | | | ipsec transform
744 | NIC PMD | <------ Add/Remove SA to/from hw context
754 * Add/Delete SA flow:
755 To add a new inline SA construct a rte_flow_item for Ethernet + IP + ESP
756 using the SA selectors and the ``rte_crypto_ipsec_xform`` as the ``rte_flow_action``.
757 Note that any rte_flow_items may be empty, which means it is not checked.
759 .. code-block:: console
761 In its most basic form, IPsec flow specification is as follows:
762 +-------+ +----------+ +--------+ +-----+
763 | Eth | -> | IP4/6 | -> | ESP | -> | END |
764 +-------+ +----------+ +--------+ +-----+
766 However, the API can represent, IPsec crypto offload with any encapsulation:
767 +-------+ +--------+ +-----+
768 | Eth | -> ... -> | ESP | -> | END |
769 +-------+ +--------+ +-----+