4 Redistribution and use in source and binary forms, with or without
5 modification, are permitted provided that the following conditions
8 * Redistributions of source code must retain the above copyright
9 notice, this list of conditions and the following disclaimer.
10 * Redistributions in binary form must reproduce the above copyright
11 notice, this list of conditions and the following disclaimer in
12 the documentation and/or other materials provided with the
14 * Neither the name of NXP nor the names of its
15 contributors may be used to endorse or promote products derived
16 from this software without specific prior written permission.
18 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
19 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
20 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
21 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
22 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
23 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
24 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
25 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
26 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
27 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
28 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
34 The security library provides a framework for management and provisioning
35 of security protocol operations offloaded to hardware based devices. The
36 library defines generic APIs to create and free security sessions which can
37 support full protocol offload as well as inline crypto operation with
38 NIC or crypto devices. The framework currently only supports the IPSec protocol
39 and associated operations, other protocols will be added in future.
44 The security library provides an additional offload capability to an existing
45 crypto device and/or ethernet device.
47 .. code-block:: console
53 +-----------+ +--------------+
54 | NIC PMD | | CRYPTO PMD |
55 +-----------+ +--------------+
59 Currently, the security library does not support the case of multi-process.
60 It will be updated in the future releases.
62 The supported offload types are explained in the sections below.
67 RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO:
68 The crypto processing for security protocol (e.g. IPSec) is processed
69 inline during receive and transmission on NIC port. The flow based
70 security action should be configured on the port.
72 Ingress Data path - The packet is decrypted in RX path and relevant
73 crypto status is set in Rx descriptors. After the successful inline
74 crypto processing the packet is presented to host as a regular Rx packet
75 however all security protocol related headers are still attached to the
76 packet. e.g. In case of IPSec, the IPSec tunnel headers (if any),
77 ESP/AH headers will remain in the packet but the received packet
78 contains the decrypted data where the encrypted data was when the packet
79 arrived. The driver Rx path check the descriptors and and based on the
80 crypto status sets additional flags in the rte_mbuf.ol_flags field.
84 The underlying device may not support crypto processing for all ingress packet
85 matching to a particular flow (e.g. fragmented packets), such packets will
86 be passed as encrypted packets. It is the responsibility of application to
87 process such encrypted packets using other crypto driver instance.
89 Egress Data path - The software prepares the egress packet by adding
90 relevant security protocol headers. Only the data will not be
91 encrypted by the software. The driver will accordingly configure the
92 tx descriptors. The hardware device will encrypt the data before sending the
97 The underlying device may support post encryption TSO.
99 .. code-block:: console
110 | | Tunnel | | <------ Add tunnel header to packet
113 | | ESP | | <------ Add ESP header without trailer to packet
114 | | | | <------ Mark packet to be offloaded, add trailer
115 | +------|------+ | meta-data to mbuf
124 | NIC PMD | <------ Set hw context for inline crypto offload
129 | HW ACCELERATED | <------ Packet Encryption and
130 | NIC | Authentication happens inline
135 Inline protocol offload
136 ~~~~~~~~~~~~~~~~~~~~~~~
138 RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL:
139 The crypto and protocol processing for security protocol (e.g. IPSec)
140 is processed inline during receive and transmission. The flow based
141 security action should be configured on the port.
143 Ingress Data path - The packet is decrypted in the RX path and relevant
144 crypto status is set in the Rx descriptors. After the successful inline
145 crypto processing the packet is presented to the host as a regular Rx packet
146 but all security protocol related headers are optionally removed from the
147 packet. e.g. in the case of IPSec, the IPSec tunnel headers (if any),
148 ESP/AH headers will be removed from the packet and the received packet
149 will contains the decrypted packet only. The driver Rx path checks the
150 descriptors and based on the crypto status sets additional flags in
151 ``rte_mbuf.ol_flags`` field.
155 The underlying device in this case is stateful. It is expected that
156 the device shall support crypto processing for all kind of packets matching
157 to a given flow, this includes fragmented packets (post reassembly).
158 E.g. in case of IPSec the device may internally manage anti-replay etc.
159 It will provide a configuration option for anti-replay behavior i.e. to drop
160 the packets or pass them to driver with error flags set in the descriptor.
162 Egress Data path - The software will send the plain packet without any
163 security protocol headers added to the packet. The driver will configure
164 the security index and other requirement in tx descriptors.
165 The hardware device will do security processing on the packet that includes
166 adding the relevant protocol headers and encrypting the data before sending
167 the packet out. The software should make sure that the buffer
168 has required head room and tail room for any protocol header addition. The
169 software may also do early fragmentation if the resultant packet is expected
170 to cross the MTU size.
175 The underlying device will manage state information required for egress
176 processing. E.g. in case of IPSec, the seq number will be added to the
177 packet, however the device shall provide indication when the sequence number
178 is about to overflow. The underlying device may support post encryption TSO.
180 .. code-block:: console
191 | | Desc | | <------ Mark packet to be offloaded
201 | NIC PMD | <------ Set hw context for inline crypto offload
206 | HW ACCELERATED | <------ Add tunnel, ESP header etc header to
207 | NIC | packet. Packet Encryption and
208 | | Authentication happens inline.
212 Lookaside protocol offload
213 ~~~~~~~~~~~~~~~~~~~~~~~~~~
215 RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL:
216 This extends librte_cryptodev to support the programming of IPsec
217 Security Association (SA) as part of a crypto session creation including
218 the definition. In addition to standard crypto processing, as defined by
219 the cryptodev, the security protocol processing is also offloaded to the
222 Decryption: The packet is sent to the crypto device for security
223 protocol processing. The device will decrypt the packet and it will also
224 optionally remove additional security headers from the packet.
225 E.g. in case of IPSec, IPSec tunnel headers (if any), ESP/AH headers
226 will be removed from the packet and the decrypted packet may contain
231 In case of IPSec the device may internally manage anti-replay etc.
232 It will provide a configuration option for anti-replay behavior i.e. to drop
233 the packets or pass them to driver with error flags set in descriptor.
235 Encryption: The software will submit the packet to cryptodev as usual
236 for encryption, the hardware device in this case will also add the relevant
237 security protocol header along with encrypting the packet. The software
238 should make sure that the buffer has required head room and tail room
239 for any protocol header addition.
243 In the case of IPSec, the seq number will be added to the packet,
244 It shall provide an indication when the sequence number is about to
247 .. code-block:: console
255 | | SADB lookup | | <------ SA maps to cryptodev session
258 | | \--------------------\
259 | | Crypto | | | <- Crypto processing through
260 | | /----------------\ | inline crypto PMD
261 | +------|------+ | | |
262 +--------V--------+ | |
264 +--------V--------+ | | create <-- SA is added to hw
265 | L2 Stack | | | inline using existing create
266 +--------|--------+ | | session sym session APIs
268 +--------V--------+ +---|---|----V---+
269 | | | \---/ | | <--- Add tunnel, ESP header etc
270 | NIC PMD | | INLINE | | header to packet.Packet
271 | | | CRYPTO PMD | | Encryption/Decryption and
272 +--------|--------+ +----------------+ Authentication happens
279 Device Features and Capabilities
280 ---------------------------------
282 Device Capabilities For Security Operations
283 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
285 The device (crypto or ethernet) capabilities which support security operations,
286 are defined by the security action type, security protocol, protocol
287 capabilities and corresponding crypto capabilities for security. For the full
288 scope of the Security capability see definition of rte_security_capability
289 structure in the *DPDK API Reference*.
293 struct rte_security_capability;
295 Each driver (crypto or ethernet) defines its own private array of capabilities
296 for the operations it supports. Below is an example of the capabilities for a
297 PMD which supports the IPSec protocol.
301 static const struct rte_security_capability pmd_security_capabilities[] = {
302 { /* IPsec Lookaside Protocol offload ESP Tunnel Egress */
303 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL,
304 .protocol = RTE_SECURITY_PROTOCOL_IPSEC,
306 .proto = RTE_SECURITY_IPSEC_SA_PROTO_ESP,
307 .mode = RTE_SECURITY_IPSEC_SA_MODE_TUNNEL,
308 .direction = RTE_SECURITY_IPSEC_SA_DIR_EGRESS,
311 .crypto_capabilities = pmd_capabilities
313 { /* IPsec Lookaside Protocol offload ESP Tunnel Ingress */
314 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL,
315 .protocol = RTE_SECURITY_PROTOCOL_IPSEC,
317 .proto = RTE_SECURITY_IPSEC_SA_PROTO_ESP,
318 .mode = RTE_SECURITY_IPSEC_SA_MODE_TUNNEL,
319 .direction = RTE_SECURITY_IPSEC_SA_DIR_INGRESS,
322 .crypto_capabilities = pmd_capabilities
325 .action = RTE_SECURITY_ACTION_TYPE_NONE
328 static const struct rte_cryptodev_capabilities pmd_capabilities[] = {
330 .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
332 .xform_type = RTE_CRYPTO_SYM_XFORM_AUTH,
334 .algo = RTE_CRYPTO_AUTH_SHA1_HMAC,
352 .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
354 .xform_type = RTE_CRYPTO_SYM_XFORM_CIPHER,
356 .algo = RTE_CRYPTO_CIPHER_AES_CBC,
374 Capabilities Discovery
375 ~~~~~~~~~~~~~~~~~~~~~~
377 Discovering the features and capabilities of a driver (crypto/ethernet)
378 is achieved through the ``rte_security_capabilities_get()`` function.
382 const struct rte_security_capability *rte_security_capabilities_get(uint16_t id);
384 This allows the user to query a specific driver and get all device
385 security capabilities. It returns an array of ``rte_security_capability`` structures
386 which contains all the capabilities for that device.
388 Security Session Create/Free
389 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
391 Security Sessions are created to store the immutable fields of a particular Security
392 Association for a particular protocol which is defined by a security session
393 configuration structure which is used in the operation processing of a packet flow.
394 Sessions are used to manage protocol specific information as well as crypto parameters.
395 Security sessions cache this immutable data in a optimal way for the underlying PMD
396 and this allows further acceleration of the offload of Crypto workloads.
398 The Security framework provides APIs to create and free sessions for crypto/ethernet
399 devices, where sessions are mempool objects. It is the application's responsibility
400 to create and manage the session mempools. The mempool object size should be able to
401 accommodate the driver's private data of security session.
403 Once the session mempools have been created, ``rte_security_session_create()``
404 is used to allocate and initialize a session for the required crypto/ethernet device.
406 Session APIs need a parameter ``rte_security_ctx`` to identify the crypto/ethernet
407 security ops. This parameter can be retrieved using the APIs
408 ``rte_cryptodev_get_sec_ctx()`` (for crypto device) or ``rte_eth_dev_get_sec_ctx``
411 Sessions already created can be updated with ``rte_security_session_update()``.
413 When a session is no longer used, the user must call ``rte_security_session_destroy()``
414 to free the driver private session data and return the memory back to the mempool.
416 For look aside protocol offload to hardware crypto device, the ``rte_crypto_op``
417 created by the application is attached to the security session by the API
418 ``rte_security_attach_session()``.
420 For Inline Crypto and Inline protocol offload, device specific defined metadata is
421 updated in the mbuf using ``rte_security_set_pkt_metadata()`` if
422 ``DEV_TX_OFFLOAD_SEC_NEED_MDATA`` is set.
424 Security session configuration
425 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
427 Security Session configuration structure is defined as ``rte_security_session_conf``
431 struct rte_security_session_conf {
432 enum rte_security_session_action_type action_type;
433 /**< Type of action to be performed on the session */
434 enum rte_security_session_protocol protocol;
435 /**< Security protocol to be configured */
437 struct rte_security_ipsec_xform ipsec;
438 struct rte_security_macsec_xform macsec;
440 /**< Configuration parameters for security session */
441 struct rte_crypto_sym_xform *crypto_xform;
442 /**< Security Session Crypto Transformations */
445 The configuration structure reuses the ``rte_crypto_sym_xform`` struct for crypto related
446 configuration. The ``rte_security_session_action_type`` struct is used to specify whether the
447 session is configured for Lookaside Protocol offload or Inline Crypto or Inline Protocol
452 enum rte_security_session_action_type {
453 RTE_SECURITY_ACTION_TYPE_NONE,
454 /**< No security actions */
455 RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO,
456 /**< Crypto processing for security protocol is processed inline
457 * during transmission */
458 RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL,
459 /**< All security protocol processing is performed inline during
461 RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL
462 /**< All security protocol processing including crypto is performed
463 * on a lookaside accelerator */
466 The ``rte_security_session_protocol`` is defined as
470 enum rte_security_session_protocol {
471 RTE_SECURITY_PROTOCOL_IPSEC,
472 /**< IPsec Protocol */
473 RTE_SECURITY_PROTOCOL_MACSEC,
474 /**< MACSec Protocol */
477 Currently the library defines configuration parameters for IPSec only. For other
478 protocols like MACSec, structures and enums are defined as place holders which
479 will be updated in the future.
481 IPsec related configuration parameters are defined in ``rte_security_ipsec_xform``
485 struct rte_security_ipsec_xform {
487 /**< SA security parameter index */
490 struct rte_security_ipsec_sa_options options;
491 /**< various SA options */
492 enum rte_security_ipsec_sa_direction direction;
493 /**< IPSec SA Direction - Egress/Ingress */
494 enum rte_security_ipsec_sa_protocol proto;
495 /**< IPsec SA Protocol - AH/ESP */
496 enum rte_security_ipsec_sa_mode mode;
497 /**< IPsec SA Mode - transport/tunnel */
498 struct rte_security_ipsec_tunnel_param tunnel;
499 /**< Tunnel parameters, NULL for transport mode */
506 The rte_security Library API is described in the *DPDK API Reference* document.
508 Flow based Security Session
509 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
511 In the case of NIC based offloads, the security session specified in the
512 'rte_flow_action_security' must be created on the same port as the
513 flow action that is being specified.
515 The ingress/egress flow attribute should match that specified in the security
516 session if the security session supports the definition of the direction.
518 Multiple flows can be configured to use the same security session. For
519 example if the security session specifies an egress IPsec SA, then multiple
520 flows can be specified to that SA. In the case of an ingress IPsec SA then
521 it is only valid to have a single flow to map to that security session.
523 .. code-block:: console
529 | IPsec SA | <------ Build security flow action of
530 | | | ipsec transform
539 | NIC PMD | <------ Add/Remove SA to/from hw context
549 * Add/Delete SA flow:
550 To add a new inline SA construct a rte_flow_item for Ethernet + IP + ESP
551 using the SA selectors and the ``rte_crypto_ipsec_xform`` as the ``rte_flow_action``.
552 Note that any rte_flow_items may be empty, which means it is not checked.
554 .. code-block:: console
556 In its most basic form, IPsec flow specification is as follows:
557 +-------+ +----------+ +--------+ +-----+
558 | Eth | -> | IP4/6 | -> | ESP | -> | END |
559 +-------+ +----------+ +--------+ +-----+
561 However, the API can represent, IPsec crypto offload with any encapsulation:
562 +-------+ +--------+ +-----+
563 | Eth | -> ... -> | ESP | -> | END |
564 +-------+ +--------+ +-----+