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