1.. SPDX-License-Identifier: BSD-3-Clause 2 Copyright 2017 NXP 3 4 5 6Security Library 7================ 8 9The security library provides a framework for management and provisioning 10of security protocol operations offloaded to hardware based devices. The 11library defines generic APIs to create and free security sessions which can 12support full protocol offload as well as inline crypto operation with 13NIC or crypto devices. The framework currently only supports the IPSec protocol 14and associated operations, other protocols will be added in future. 15 16Design Principles 17----------------- 18 19The security library provides an additional offload capability to an existing 20crypto device and/or ethernet device. 21 22.. code-block:: console 23 24 +---------------+ 25 | rte_security | 26 +---------------+ 27 \ / 28 +-----------+ +--------------+ 29 | NIC PMD | | CRYPTO PMD | 30 +-----------+ +--------------+ 31 32.. note:: 33 34 Currently, the security library does not support the case of multi-process. 35 It will be updated in the future releases. 36 37The supported offload types are explained in the sections below. 38 39Inline Crypto 40~~~~~~~~~~~~~ 41 42RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO: 43The crypto processing for security protocol (e.g. IPSec) is processed 44inline during receive and transmission on NIC port. The flow based 45security action should be configured on the port. 46 47Ingress Data path - The packet is decrypted in RX path and relevant 48crypto status is set in Rx descriptors. After the successful inline 49crypto processing the packet is presented to host as a regular Rx packet 50however all security protocol related headers are still attached to the 51packet. e.g. In case of IPSec, the IPSec tunnel headers (if any), 52ESP/AH headers will remain in the packet but the received packet 53contains the decrypted data where the encrypted data was when the packet 54arrived. The driver Rx path check the descriptors and and based on the 55crypto status sets additional flags in the rte_mbuf.ol_flags field. 56 57.. note:: 58 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. 63 64Egress Data path - The software prepares the egress packet by adding 65relevant security protocol headers. Only the data will not be 66encrypted by the software. The driver will accordingly configure the 67tx descriptors. The hardware device will encrypt the data before sending the 68the packet out. 69 70.. note:: 71 72 The underlying device may support post encryption TSO. 73 74.. code-block:: console 75 76 Egress Data Path 77 | 78 +--------|--------+ 79 | egress IPsec | 80 | | | 81 | +------V------+ | 82 | | SADB lookup | | 83 | +------|------+ | 84 | +------V------+ | 85 | | Tunnel | | <------ Add tunnel header to packet 86 | +------|------+ | 87 | +------V------+ | 88 | | ESP | | <------ Add ESP header without trailer to packet 89 | | | | <------ Mark packet to be offloaded, add trailer 90 | +------|------+ | meta-data to mbuf 91 +--------V--------+ 92 | 93 +--------V--------+ 94 | L2 Stack | 95 +--------|--------+ 96 | 97 +--------V--------+ 98 | | 99 | NIC PMD | <------ Set hw context for inline crypto offload 100 | | 101 +--------|--------+ 102 | 103 +--------|--------+ 104 | HW ACCELERATED | <------ Packet Encryption and 105 | NIC | Authentication happens inline 106 | | 107 +-----------------+ 108 109 110Inline protocol offload 111~~~~~~~~~~~~~~~~~~~~~~~ 112 113RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL: 114The crypto and protocol processing for security protocol (e.g. IPSec) 115is processed inline during receive and transmission. The flow based 116security action should be configured on the port. 117 118Ingress Data path - The packet is decrypted in the RX path and relevant 119crypto status is set in the Rx descriptors. After the successful inline 120crypto processing the packet is presented to the host as a regular Rx packet 121but all security protocol related headers are optionally removed from the 122packet. e.g. in the case of IPSec, the IPSec tunnel headers (if any), 123ESP/AH headers will be removed from the packet and the received packet 124will contains the decrypted packet only. The driver Rx path checks the 125descriptors and based on the crypto status sets additional flags in 126``rte_mbuf.ol_flags`` field. 127 128.. note:: 129 130 The underlying device in this case is stateful. It is expected that 131 the device shall support crypto processing for all kind of packets matching 132 to a given flow, this includes fragmented packets (post reassembly). 133 E.g. in case of IPSec the device may internally manage anti-replay etc. 134 It will provide a configuration option for anti-replay behavior i.e. to drop 135 the packets or pass them to driver with error flags set in the descriptor. 136 137Egress Data path - The software will send the plain packet without any 138security protocol headers added to the packet. The driver will configure 139the security index and other requirement in tx descriptors. 140The hardware device will do security processing on the packet that includes 141adding the relevant protocol headers and encrypting the data before sending 142the packet out. The software should make sure that the buffer 143has required head room and tail room for any protocol header addition. The 144software may also do early fragmentation if the resultant packet is expected 145to cross the MTU size. 146 147 148.. note:: 149 150 The underlying device will manage state information required for egress 151 processing. E.g. in case of IPSec, the seq number will be added to the 152 packet, however the device shall provide indication when the sequence number 153 is about to overflow. The underlying device may support post encryption TSO. 154 155.. code-block:: console 156 157 Egress Data Path 158 | 159 +--------|--------+ 160 | egress IPsec | 161 | | | 162 | +------V------+ | 163 | | SADB lookup | | 164 | +------|------+ | 165 | +------V------+ | 166 | | Desc | | <------ Mark packet to be offloaded 167 | +------|------+ | 168 +--------V--------+ 169 | 170 +--------V--------+ 171 | L2 Stack | 172 +--------|--------+ 173 | 174 +--------V--------+ 175 | | 176 | NIC PMD | <------ Set hw context for inline crypto offload 177 | | 178 +--------|--------+ 179 | 180 +--------|--------+ 181 | HW ACCELERATED | <------ Add tunnel, ESP header etc header to 182 | NIC | packet. Packet Encryption and 183 | | Authentication happens inline. 184 +-----------------+ 185 186 187Lookaside protocol offload 188~~~~~~~~~~~~~~~~~~~~~~~~~~ 189 190RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL: 191This extends librte_cryptodev to support the programming of IPsec 192Security Association (SA) as part of a crypto session creation including 193the definition. In addition to standard crypto processing, as defined by 194the cryptodev, the security protocol processing is also offloaded to the 195crypto device. 196 197Decryption: The packet is sent to the crypto device for security 198protocol processing. The device will decrypt the packet and it will also 199optionally remove additional security headers from the packet. 200E.g. in case of IPSec, IPSec tunnel headers (if any), ESP/AH headers 201will be removed from the packet and the decrypted packet may contain 202plain data only. 203 204.. note:: 205 206 In case of IPSec the device may internally manage anti-replay etc. 207 It will provide a configuration option for anti-replay behavior i.e. to drop 208 the packets or pass them to driver with error flags set in descriptor. 209 210Encryption: The software will submit the packet to cryptodev as usual 211for encryption, the hardware device in this case will also add the relevant 212security protocol header along with encrypting the packet. The software 213should make sure that the buffer has required head room and tail room 214for any protocol header addition. 215 216.. note:: 217 218 In the case of IPSec, the seq number will be added to the packet, 219 It shall provide an indication when the sequence number is about to 220 overflow. 221 222.. code-block:: console 223 224 Egress Data Path 225 | 226 +--------|--------+ 227 | egress IPsec | 228 | | | 229 | +------V------+ | 230 | | SADB lookup | | <------ SA maps to cryptodev session 231 | +------|------+ | 232 | +------|------+ | 233 | | \--------------------\ 234 | | Crypto | | | <- Crypto processing through 235 | | /----------------\ | inline crypto PMD 236 | +------|------+ | | | 237 +--------V--------+ | | 238 | | | 239 +--------V--------+ | | create <-- SA is added to hw 240 | L2 Stack | | | inline using existing create 241 +--------|--------+ | | session sym session APIs 242 | | | | 243 +--------V--------+ +---|---|----V---+ 244 | | | \---/ | | <--- Add tunnel, ESP header etc 245 | NIC PMD | | INLINE | | header to packet.Packet 246 | | | CRYPTO PMD | | Encryption/Decryption and 247 +--------|--------+ +----------------+ Authentication happens 248 | inline. 249 +--------|--------+ 250 | NIC | 251 +--------|--------+ 252 V 253 254Device Features and Capabilities 255--------------------------------- 256 257Device Capabilities For Security Operations 258~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 259 260The device (crypto or ethernet) capabilities which support security operations, 261are defined by the security action type, security protocol, protocol 262capabilities and corresponding crypto capabilities for security. For the full 263scope of the Security capability see definition of rte_security_capability 264structure in the *DPDK API Reference*. 265 266.. code-block:: c 267 268 struct rte_security_capability; 269 270Each driver (crypto or ethernet) defines its own private array of capabilities 271for the operations it supports. Below is an example of the capabilities for a 272PMD which supports the IPSec protocol. 273 274.. code-block:: c 275 276 static const struct rte_security_capability pmd_security_capabilities[] = { 277 { /* IPsec Lookaside Protocol offload ESP Tunnel Egress */ 278 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL, 279 .protocol = RTE_SECURITY_PROTOCOL_IPSEC, 280 .ipsec = { 281 .proto = RTE_SECURITY_IPSEC_SA_PROTO_ESP, 282 .mode = RTE_SECURITY_IPSEC_SA_MODE_TUNNEL, 283 .direction = RTE_SECURITY_IPSEC_SA_DIR_EGRESS, 284 .options = { 0 } 285 }, 286 .crypto_capabilities = pmd_capabilities 287 }, 288 { /* IPsec Lookaside Protocol offload ESP Tunnel Ingress */ 289 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL, 290 .protocol = RTE_SECURITY_PROTOCOL_IPSEC, 291 .ipsec = { 292 .proto = RTE_SECURITY_IPSEC_SA_PROTO_ESP, 293 .mode = RTE_SECURITY_IPSEC_SA_MODE_TUNNEL, 294 .direction = RTE_SECURITY_IPSEC_SA_DIR_INGRESS, 295 .options = { 0 } 296 }, 297 .crypto_capabilities = pmd_capabilities 298 }, 299 { 300 .action = RTE_SECURITY_ACTION_TYPE_NONE 301 } 302 }; 303 static const struct rte_cryptodev_capabilities pmd_capabilities[] = { 304 { /* SHA1 HMAC */ 305 .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC, 306 .sym = { 307 .xform_type = RTE_CRYPTO_SYM_XFORM_AUTH, 308 .auth = { 309 .algo = RTE_CRYPTO_AUTH_SHA1_HMAC, 310 .block_size = 64, 311 .key_size = { 312 .min = 64, 313 .max = 64, 314 .increment = 0 315 }, 316 .digest_size = { 317 .min = 12, 318 .max = 12, 319 .increment = 0 320 }, 321 .aad_size = { 0 }, 322 .iv_size = { 0 } 323 } 324 } 325 }, 326 { /* AES CBC */ 327 .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC, 328 .sym = { 329 .xform_type = RTE_CRYPTO_SYM_XFORM_CIPHER, 330 .cipher = { 331 .algo = RTE_CRYPTO_CIPHER_AES_CBC, 332 .block_size = 16, 333 .key_size = { 334 .min = 16, 335 .max = 32, 336 .increment = 8 337 }, 338 .iv_size = { 339 .min = 16, 340 .max = 16, 341 .increment = 0 342 } 343 } 344 } 345 } 346 } 347 348 349Capabilities Discovery 350~~~~~~~~~~~~~~~~~~~~~~ 351 352Discovering the features and capabilities of a driver (crypto/ethernet) 353is achieved through the ``rte_security_capabilities_get()`` function. 354 355.. code-block:: c 356 357 const struct rte_security_capability *rte_security_capabilities_get(uint16_t id); 358 359This allows the user to query a specific driver and get all device 360security capabilities. It returns an array of ``rte_security_capability`` structures 361which contains all the capabilities for that device. 362 363Security Session Create/Free 364~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 365 366Security Sessions are created to store the immutable fields of a particular Security 367Association for a particular protocol which is defined by a security session 368configuration structure which is used in the operation processing of a packet flow. 369Sessions are used to manage protocol specific information as well as crypto parameters. 370Security sessions cache this immutable data in a optimal way for the underlying PMD 371and this allows further acceleration of the offload of Crypto workloads. 372 373The Security framework provides APIs to create and free sessions for crypto/ethernet 374devices, where sessions are mempool objects. It is the application's responsibility 375to create and manage the session mempools. The mempool object size should be able to 376accommodate the driver's private data of security session. 377 378Once the session mempools have been created, ``rte_security_session_create()`` 379is used to allocate and initialize a session for the required crypto/ethernet device. 380 381Session APIs need a parameter ``rte_security_ctx`` to identify the crypto/ethernet 382security ops. This parameter can be retrieved using the APIs 383``rte_cryptodev_get_sec_ctx()`` (for crypto device) or ``rte_eth_dev_get_sec_ctx`` 384(for ethernet port). 385 386Sessions already created can be updated with ``rte_security_session_update()``. 387 388When a session is no longer used, the user must call ``rte_security_session_destroy()`` 389to free the driver private session data and return the memory back to the mempool. 390 391For look aside protocol offload to hardware crypto device, the ``rte_crypto_op`` 392created by the application is attached to the security session by the API 393``rte_security_attach_session()``. 394 395For Inline Crypto and Inline protocol offload, device specific defined metadata is 396updated in the mbuf using ``rte_security_set_pkt_metadata()`` if 397``DEV_TX_OFFLOAD_SEC_NEED_MDATA`` is set. 398 399Security session configuration 400~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 401 402Security Session configuration structure is defined as ``rte_security_session_conf`` 403 404.. code-block:: c 405 406 struct rte_security_session_conf { 407 enum rte_security_session_action_type action_type; 408 /**< Type of action to be performed on the session */ 409 enum rte_security_session_protocol protocol; 410 /**< Security protocol to be configured */ 411 union { 412 struct rte_security_ipsec_xform ipsec; 413 struct rte_security_macsec_xform macsec; 414 }; 415 /**< Configuration parameters for security session */ 416 struct rte_crypto_sym_xform *crypto_xform; 417 /**< Security Session Crypto Transformations */ 418 }; 419 420The configuration structure reuses the ``rte_crypto_sym_xform`` struct for crypto related 421configuration. The ``rte_security_session_action_type`` struct is used to specify whether the 422session is configured for Lookaside Protocol offload or Inline Crypto or Inline Protocol 423Offload. 424 425.. code-block:: c 426 427 enum rte_security_session_action_type { 428 RTE_SECURITY_ACTION_TYPE_NONE, 429 /**< No security actions */ 430 RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO, 431 /**< Crypto processing for security protocol is processed inline 432 * during transmission */ 433 RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL, 434 /**< All security protocol processing is performed inline during 435 * transmission */ 436 RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL 437 /**< All security protocol processing including crypto is performed 438 * on a lookaside accelerator */ 439 }; 440 441The ``rte_security_session_protocol`` is defined as 442 443.. code-block:: c 444 445 enum rte_security_session_protocol { 446 RTE_SECURITY_PROTOCOL_IPSEC, 447 /**< IPsec Protocol */ 448 RTE_SECURITY_PROTOCOL_MACSEC, 449 /**< MACSec Protocol */ 450 }; 451 452Currently the library defines configuration parameters for IPSec only. For other 453protocols like MACSec, structures and enums are defined as place holders which 454will be updated in the future. 455 456IPsec related configuration parameters are defined in ``rte_security_ipsec_xform`` 457 458.. code-block:: c 459 460 struct rte_security_ipsec_xform { 461 uint32_t spi; 462 /**< SA security parameter index */ 463 uint32_t salt; 464 /**< SA salt */ 465 struct rte_security_ipsec_sa_options options; 466 /**< various SA options */ 467 enum rte_security_ipsec_sa_direction direction; 468 /**< IPSec SA Direction - Egress/Ingress */ 469 enum rte_security_ipsec_sa_protocol proto; 470 /**< IPsec SA Protocol - AH/ESP */ 471 enum rte_security_ipsec_sa_mode mode; 472 /**< IPsec SA Mode - transport/tunnel */ 473 struct rte_security_ipsec_tunnel_param tunnel; 474 /**< Tunnel parameters, NULL for transport mode */ 475 }; 476 477 478Security API 479~~~~~~~~~~~~ 480 481The rte_security Library API is described in the *DPDK API Reference* document. 482 483Flow based Security Session 484~~~~~~~~~~~~~~~~~~~~~~~~~~~ 485 486In the case of NIC based offloads, the security session specified in the 487'rte_flow_action_security' must be created on the same port as the 488flow action that is being specified. 489 490The ingress/egress flow attribute should match that specified in the security 491session if the security session supports the definition of the direction. 492 493Multiple flows can be configured to use the same security session. For 494example if the security session specifies an egress IPsec SA, then multiple 495flows can be specified to that SA. In the case of an ingress IPsec SA then 496it is only valid to have a single flow to map to that security session. 497 498.. code-block:: console 499 500 Configuration Path 501 | 502 +--------|--------+ 503 | Add/Remove | 504 | IPsec SA | <------ Build security flow action of 505 | | | ipsec transform 506 |--------|--------| 507 | 508 +--------V--------+ 509 | Flow API | 510 +--------|--------+ 511 | 512 +--------V--------+ 513 | | 514 | NIC PMD | <------ Add/Remove SA to/from hw context 515 | | 516 +--------|--------+ 517 | 518 +--------|--------+ 519 | HW ACCELERATED | 520 | NIC | 521 | | 522 +--------|--------+ 523 524* Add/Delete SA flow: 525 To add a new inline SA construct a rte_flow_item for Ethernet + IP + ESP 526 using the SA selectors and the ``rte_crypto_ipsec_xform`` as the ``rte_flow_action``. 527 Note that any rte_flow_items may be empty, which means it is not checked. 528 529.. code-block:: console 530 531 In its most basic form, IPsec flow specification is as follows: 532 +-------+ +----------+ +--------+ +-----+ 533 | Eth | -> | IP4/6 | -> | ESP | -> | END | 534 +-------+ +----------+ +--------+ +-----+ 535 536 However, the API can represent, IPsec crypto offload with any encapsulation: 537 +-------+ +--------+ +-----+ 538 | Eth | -> ... -> | ESP | -> | END | 539 +-------+ +--------+ +-----+ 540