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 and PDCP
14 protocol and associated operations, other protocols will be added in future.
19 The security library provides an additional offload capability to an existing
20 crypto device and/or ethernet device.
22 .. code-block:: console
28 +-----------+ +--------------+
29 | NIC PMD | | CRYPTO PMD |
30 +-----------+ +--------------+
34 Currently, the security library does not support the case of multi-process.
35 It will be updated in the future releases.
37 The supported offload types are explained in the sections below.
42 RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO:
43 The crypto processing for security protocol (e.g. IPsec) is processed
44 inline during receive and transmission on NIC port. The flow based
45 security action should be configured on the port.
47 Ingress Data path - The packet is decrypted in RX path and relevant
48 crypto status is set in Rx descriptors. After the successful inline
49 crypto processing the packet is presented to host as a regular Rx packet
50 however all security protocol related headers are still attached to the
51 packet. e.g. In case of IPsec, the IPsec tunnel headers (if any),
52 ESP/AH headers will remain in the packet but the received packet
53 contains the decrypted data where the encrypted data was when the packet
54 arrived. The driver Rx path check the descriptors and and based on the
55 crypto status sets additional flags in the rte_mbuf.ol_flags field.
59 The underlying device may not support crypto processing for all ingress packet
60 matching to a particular flow (e.g. fragmented packets), such packets will
61 be passed as encrypted packets. It is the responsibility of application to
62 process such encrypted packets using other crypto driver instance.
64 Egress Data path - The software prepares the egress packet by adding
65 relevant security protocol headers. Only the data will not be
66 encrypted by the software. The driver will accordingly configure the
67 tx descriptors. The hardware device will encrypt the data before sending the
72 The underlying device may support post encryption TSO.
74 .. code-block:: console
85 | | Tunnel | | <------ Add tunnel header to packet
88 | | ESP | | <------ Add ESP header without trailer to packet
89 | | | | <------ Mark packet to be offloaded, add trailer
90 | +------|------+ | meta-data to mbuf
99 | NIC PMD | <------ Set hw context for inline crypto offload
104 | HW ACCELERATED | <------ Packet Encryption and
105 | NIC | Authentication happens inline
110 Inline protocol offload
111 ~~~~~~~~~~~~~~~~~~~~~~~
113 RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL:
114 The crypto and protocol processing for security protocol (e.g. IPsec)
115 is processed inline during receive and transmission. The flow based
116 security action should be configured on the port.
118 Ingress Data path - The packet is decrypted in the RX path and relevant
119 crypto status is set in the Rx descriptors. After the successful inline
120 crypto processing the packet is presented to the host as a regular Rx packet
121 but all security protocol related headers are optionally removed from the
122 packet. e.g. in the case of IPsec, the IPsec tunnel headers (if any),
123 ESP/AH headers will be removed from the packet and the received packet
124 will contains the decrypted packet only. The driver Rx path checks the
125 descriptors and based on the crypto status sets additional flags in
126 ``rte_mbuf.ol_flags`` field. The driver would also set device-specific
127 metadata in ``rte_mbuf.udata64`` field. This will allow the application
128 to identify the security processing done on the packet.
132 The underlying device in this case is stateful. It is expected that
133 the device shall support crypto processing for all kind of packets matching
134 to a given flow, this includes fragmented packets (post reassembly).
135 E.g. in case of IPsec the device may internally manage anti-replay etc.
136 It will provide a configuration option for anti-replay behavior i.e. to drop
137 the packets or pass them to driver with error flags set in the descriptor.
139 Egress Data path - The software will send the plain packet without any
140 security protocol headers added to the packet. The driver will configure
141 the security index and other requirement in tx descriptors.
142 The hardware device will do security processing on the packet that includes
143 adding the relevant protocol headers and encrypting the data before sending
144 the packet out. The software should make sure that the buffer
145 has required head room and tail room for any protocol header addition. The
146 software may also do early fragmentation if the resultant packet is expected
147 to cross the MTU size.
152 The underlying device will manage state information required for egress
153 processing. E.g. in case of IPsec, the seq number will be added to the
154 packet, however the device shall provide indication when the sequence number
155 is about to overflow. The underlying device may support post encryption TSO.
157 .. code-block:: console
168 | | Desc | | <------ Mark packet to be offloaded
178 | NIC PMD | <------ Set hw context for inline crypto offload
183 | HW ACCELERATED | <------ Add tunnel, ESP header etc header to
184 | NIC | packet. Packet Encryption and
185 | | Authentication happens inline.
189 Lookaside protocol offload
190 ~~~~~~~~~~~~~~~~~~~~~~~~~~
192 RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL:
193 This extends librte_cryptodev to support the programming of IPsec
194 Security Association (SA) as part of a crypto session creation including
195 the definition. In addition to standard crypto processing, as defined by
196 the cryptodev, the security protocol processing is also offloaded to the
199 Decryption: The packet is sent to the crypto device for security
200 protocol processing. The device will decrypt the packet and it will also
201 optionally remove additional security headers from the packet.
202 E.g. in case of IPsec, IPsec tunnel headers (if any), ESP/AH headers
203 will be removed from the packet and the decrypted packet may contain
208 In case of IPsec the device may internally manage anti-replay etc.
209 It will provide a configuration option for anti-replay behavior i.e. to drop
210 the packets or pass them to driver with error flags set in descriptor.
212 Encryption: The software will submit the packet to cryptodev as usual
213 for encryption, the hardware device in this case will also add the relevant
214 security protocol header along with encrypting the packet. The software
215 should make sure that the buffer has required head room and tail room
216 for any protocol header addition.
220 In the case of IPsec, the seq number will be added to the packet,
221 It shall provide an indication when the sequence number is about to
224 .. code-block:: console
232 | | SADB lookup | | <------ SA maps to cryptodev session
235 | | \--------------------\
236 | | Crypto | | | <- Crypto processing through
237 | | /----------------\ | inline crypto PMD
238 | +------|------+ | | |
239 +--------V--------+ | |
241 +--------V--------+ | | create <-- SA is added to hw
242 | L2 Stack | | | inline using existing create
243 +--------|--------+ | | session sym session APIs
245 +--------V--------+ +---|---|----V---+
246 | | | \---/ | | <--- Add tunnel, ESP header etc
247 | NIC PMD | | INLINE | | header to packet.Packet
248 | | | CRYPTO PMD | | Encryption/Decryption and
249 +--------|--------+ +----------------+ Authentication happens
259 Based on 3GPP TS 36.323 Evolved Universal Terrestrial Radio Access (E-UTRA);
260 Packet Data Convergence Protocol (PDCP) specification
264 Transmitting PDCP Entity Receiving PDCP Entity
266 | +-----------|-----------+
267 V | In order delivery and |
268 +---------|----------+ | Duplicate detection |
269 | Sequence Numbering | | (Data Plane only) |
270 +---------|----------+ +-----------|-----------+
272 +---------|----------+ +-----------|----------+
273 | Header Compression*| | Header Decompression*|
274 | (Data-Plane only) | | (Data Plane only) |
275 +---------|----------+ +-----------|----------+
277 +---------|-----------+ +-----------|----------+
278 | Integrity Protection| |Integrity Verification|
279 | (Control Plane only)| | (Control Plane only) |
280 +---------|-----------+ +-----------|----------+
281 +---------|-----------+ +----------|----------+
282 | Ciphering | | Deciphering |
283 +---------|-----------+ +----------|----------+
284 +---------|-----------+ +----------|----------+
285 | Add PDCP header | | Remove PDCP Header |
286 +---------|-----------+ +----------|----------+
288 +----------------->>----------------+
293 * Header Compression and decompression are not supported currently.
295 Just like IPsec, in case of PDCP also header addition/deletion, cipher/
296 de-cipher, integrity protection/verification is done based on the action
299 Device Features and Capabilities
300 ---------------------------------
302 Device Capabilities For Security Operations
303 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
305 The device (crypto or ethernet) capabilities which support security operations,
306 are defined by the security action type, security protocol, protocol
307 capabilities and corresponding crypto capabilities for security. For the full
308 scope of the Security capability see definition of rte_security_capability
309 structure in the *DPDK API Reference*.
313 struct rte_security_capability;
315 Each driver (crypto or ethernet) defines its own private array of capabilities
316 for the operations it supports. Below is an example of the capabilities for a
317 PMD which supports the IPsec and PDCP protocol.
321 static const struct rte_security_capability pmd_security_capabilities[] = {
322 { /* IPsec Lookaside Protocol offload ESP Tunnel Egress */
323 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL,
324 .protocol = RTE_SECURITY_PROTOCOL_IPSEC,
326 .proto = RTE_SECURITY_IPSEC_SA_PROTO_ESP,
327 .mode = RTE_SECURITY_IPSEC_SA_MODE_TUNNEL,
328 .direction = RTE_SECURITY_IPSEC_SA_DIR_EGRESS,
331 .crypto_capabilities = pmd_capabilities
333 { /* IPsec Lookaside Protocol offload ESP Tunnel Ingress */
334 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL,
335 .protocol = RTE_SECURITY_PROTOCOL_IPSEC,
337 .proto = RTE_SECURITY_IPSEC_SA_PROTO_ESP,
338 .mode = RTE_SECURITY_IPSEC_SA_MODE_TUNNEL,
339 .direction = RTE_SECURITY_IPSEC_SA_DIR_INGRESS,
342 .crypto_capabilities = pmd_capabilities
344 { /* PDCP Lookaside Protocol offload Data Plane */
345 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL,
346 .protocol = RTE_SECURITY_PROTOCOL_PDCP,
348 .domain = RTE_SECURITY_PDCP_MODE_DATA,
351 .crypto_capabilities = pmd_capabilities
353 { /* PDCP Lookaside Protocol offload Control */
354 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL,
355 .protocol = RTE_SECURITY_PROTOCOL_PDCP,
357 .domain = RTE_SECURITY_PDCP_MODE_CONTROL,
360 .crypto_capabilities = pmd_capabilities
363 .action = RTE_SECURITY_ACTION_TYPE_NONE
366 static const struct rte_cryptodev_capabilities pmd_capabilities[] = {
368 .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
370 .xform_type = RTE_CRYPTO_SYM_XFORM_AUTH,
372 .algo = RTE_CRYPTO_AUTH_SHA1_HMAC,
390 .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
392 .xform_type = RTE_CRYPTO_SYM_XFORM_CIPHER,
394 .algo = RTE_CRYPTO_CIPHER_AES_CBC,
412 Capabilities Discovery
413 ~~~~~~~~~~~~~~~~~~~~~~
415 Discovering the features and capabilities of a driver (crypto/ethernet)
416 is achieved through the ``rte_security_capabilities_get()`` function.
420 const struct rte_security_capability *rte_security_capabilities_get(uint16_t id);
422 This allows the user to query a specific driver and get all device
423 security capabilities. It returns an array of ``rte_security_capability`` structures
424 which contains all the capabilities for that device.
426 Security Session Create/Free
427 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
429 Security Sessions are created to store the immutable fields of a particular Security
430 Association for a particular protocol which is defined by a security session
431 configuration structure which is used in the operation processing of a packet flow.
432 Sessions are used to manage protocol specific information as well as crypto parameters.
433 Security sessions cache this immutable data in a optimal way for the underlying PMD
434 and this allows further acceleration of the offload of Crypto workloads.
436 The Security framework provides APIs to create and free sessions for crypto/ethernet
437 devices, where sessions are mempool objects. It is the application's responsibility
438 to create and manage the session mempools. The mempool object size should be able to
439 accommodate the driver's private data of security session.
441 Once the session mempools have been created, ``rte_security_session_create()``
442 is used to allocate and initialize a session for the required crypto/ethernet device.
444 Session APIs need a parameter ``rte_security_ctx`` to identify the crypto/ethernet
445 security ops. This parameter can be retrieved using the APIs
446 ``rte_cryptodev_get_sec_ctx()`` (for crypto device) or ``rte_eth_dev_get_sec_ctx``
449 Sessions already created can be updated with ``rte_security_session_update()``.
451 When a session is no longer used, the user must call ``rte_security_session_destroy()``
452 to free the driver private session data and return the memory back to the mempool.
454 For look aside protocol offload to hardware crypto device, the ``rte_crypto_op``
455 created by the application is attached to the security session by the API
456 ``rte_security_attach_session()``.
458 For Inline Crypto and Inline protocol offload, device specific defined metadata is
459 updated in the mbuf using ``rte_security_set_pkt_metadata()`` if
460 ``DEV_TX_OFFLOAD_SEC_NEED_MDATA`` is set.
462 For inline protocol offloaded ingress traffic, the application can register a
463 pointer, ``userdata`` , in the security session. When the packet is received,
464 ``rte_security_get_userdata()`` would return the userdata registered for the
465 security session which processed the packet.
469 In case of inline processed packets, ``rte_mbuf.udata64`` field would be
470 used by the driver to relay information on the security processing
471 associated with the packet. In ingress, the driver would set this in Rx
472 path while in egress, ``rte_security_set_pkt_metadata()`` would perform a
473 similar operation. The application is expected not to modify the field
474 when it has relevant info. For ingress, this device-specific 64 bit value
475 is required to derive other information (like userdata), required for
476 identifying the security processing done on the packet.
478 Security session configuration
479 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
481 Security Session configuration structure is defined as ``rte_security_session_conf``
485 struct rte_security_session_conf {
486 enum rte_security_session_action_type action_type;
487 /**< Type of action to be performed on the session */
488 enum rte_security_session_protocol protocol;
489 /**< Security protocol to be configured */
491 struct rte_security_ipsec_xform ipsec;
492 struct rte_security_macsec_xform macsec;
493 struct rte_security_pdcp_xform pdcp;
495 /**< Configuration parameters for security session */
496 struct rte_crypto_sym_xform *crypto_xform;
497 /**< Security Session Crypto Transformations */
499 /**< Application specific userdata to be saved with session */
502 The configuration structure reuses the ``rte_crypto_sym_xform`` struct for crypto related
503 configuration. The ``rte_security_session_action_type`` struct is used to specify whether the
504 session is configured for Lookaside Protocol offload or Inline Crypto or Inline Protocol
509 enum rte_security_session_action_type {
510 RTE_SECURITY_ACTION_TYPE_NONE,
511 /**< No security actions */
512 RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO,
513 /**< Crypto processing for security protocol is processed inline
514 * during transmission */
515 RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL,
516 /**< All security protocol processing is performed inline during
518 RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL
519 /**< All security protocol processing including crypto is performed
520 * on a lookaside accelerator */
523 The ``rte_security_session_protocol`` is defined as
527 enum rte_security_session_protocol {
528 RTE_SECURITY_PROTOCOL_IPSEC = 1,
529 /**< IPsec Protocol */
530 RTE_SECURITY_PROTOCOL_MACSEC,
531 /**< MACSec Protocol */
532 RTE_SECURITY_PROTOCOL_PDCP,
533 /**< PDCP Protocol */
536 Currently the library defines configuration parameters for IPsec and PDCP only.
537 For other protocols like MACSec, structures and enums are defined as place holders
538 which will be updated in the future.
540 IPsec related configuration parameters are defined in ``rte_security_ipsec_xform``
544 struct rte_security_ipsec_xform {
546 /**< SA security parameter index */
549 struct rte_security_ipsec_sa_options options;
550 /**< various SA options */
551 enum rte_security_ipsec_sa_direction direction;
552 /**< IPsec SA Direction - Egress/Ingress */
553 enum rte_security_ipsec_sa_protocol proto;
554 /**< IPsec SA Protocol - AH/ESP */
555 enum rte_security_ipsec_sa_mode mode;
556 /**< IPsec SA Mode - transport/tunnel */
557 struct rte_security_ipsec_tunnel_param tunnel;
558 /**< Tunnel parameters, NULL for transport mode */
561 PDCP related configuration parameters are defined in ``rte_security_pdcp_xform``
565 struct rte_security_pdcp_xform {
566 int8_t bearer; /**< PDCP bearer ID */
567 /** Enable in order delivery, this field shall be set only if
568 * driver/HW is capable. See RTE_SECURITY_PDCP_ORDERING_CAP.
571 /** Notify driver/HW to detect and remove duplicate packets.
572 * This field should be set only when driver/hw is capable.
573 * See RTE_SECURITY_PDCP_DUP_DETECT_CAP.
575 uint8_t remove_duplicates;
576 /** PDCP mode of operation: Control or data */
577 enum rte_security_pdcp_domain domain;
578 /** PDCP Frame Direction 0:UL 1:DL */
579 enum rte_security_pdcp_direction pkt_dir;
580 /** Sequence number size, 5/7/12/15/18 */
581 enum rte_security_pdcp_sn_size sn_size;
582 /** Starting Hyper Frame Number to be used together with the SN
583 * from the PDCP frames
586 /** HFN Threshold for key renegotiation */
587 uint32_t hfn_threshold;
594 The rte_security Library API is described in the *DPDK API Reference* document.
596 Flow based Security Session
597 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
599 In the case of NIC based offloads, the security session specified in the
600 'rte_flow_action_security' must be created on the same port as the
601 flow action that is being specified.
603 The ingress/egress flow attribute should match that specified in the security
604 session if the security session supports the definition of the direction.
606 Multiple flows can be configured to use the same security session. For
607 example if the security session specifies an egress IPsec SA, then multiple
608 flows can be specified to that SA. In the case of an ingress IPsec SA then
609 it is only valid to have a single flow to map to that security session.
611 .. code-block:: console
617 | IPsec SA | <------ Build security flow action of
618 | | | ipsec transform
627 | NIC PMD | <------ Add/Remove SA to/from hw context
637 * Add/Delete SA flow:
638 To add a new inline SA construct a rte_flow_item for Ethernet + IP + ESP
639 using the SA selectors and the ``rte_crypto_ipsec_xform`` as the ``rte_flow_action``.
640 Note that any rte_flow_items may be empty, which means it is not checked.
642 .. code-block:: console
644 In its most basic form, IPsec flow specification is as follows:
645 +-------+ +----------+ +--------+ +-----+
646 | Eth | -> | IP4/6 | -> | ESP | -> | END |
647 +-------+ +----------+ +--------+ +-----+
649 However, the API can represent, IPsec crypto offload with any encapsulation:
650 +-------+ +--------+ +-----+
651 | Eth | -> ... -> | ESP | -> | END |
652 +-------+ +--------+ +-----+