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 and PDCP 14protocol and 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 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 68packet 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. The driver would also set device-specific 127metadata in ``rte_mbuf.udata64`` field. This will allow the application 128to identify the security processing done on the packet. 129 130.. note:: 131 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. 138 139Egress Data path - The software will send the plain packet without any 140security protocol headers added to the packet. The driver will configure 141the security index and other requirement in tx descriptors. 142The hardware device will do security processing on the packet that includes 143adding the relevant protocol headers and encrypting the data before sending 144the packet out. The software should make sure that the buffer 145has required head room and tail room for any protocol header addition. The 146software may also do early fragmentation if the resultant packet is expected 147to cross the MTU size. 148 149 150.. note:: 151 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. 156 157.. code-block:: console 158 159 Egress Data Path 160 | 161 +--------|--------+ 162 | egress IPsec | 163 | | | 164 | +------V------+ | 165 | | SADB lookup | | 166 | +------|------+ | 167 | +------V------+ | 168 | | Desc | | <------ Mark packet to be offloaded 169 | +------|------+ | 170 +--------V--------+ 171 | 172 +--------V--------+ 173 | L2 Stack | 174 +--------|--------+ 175 | 176 +--------V--------+ 177 | | 178 | NIC PMD | <------ Set hw context for inline crypto offload 179 | | 180 +--------|--------+ 181 | 182 +--------|--------+ 183 | HW ACCELERATED | <------ Add tunnel, ESP header etc header to 184 | NIC | packet. Packet Encryption and 185 | | Authentication happens inline. 186 +-----------------+ 187 188 189Lookaside protocol offload 190~~~~~~~~~~~~~~~~~~~~~~~~~~ 191 192RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL: 193This extends librte_cryptodev to support the programming of IPsec 194Security Association (SA) as part of a crypto session creation including 195the definition. In addition to standard crypto processing, as defined by 196the cryptodev, the security protocol processing is also offloaded to the 197crypto device. 198 199Decryption: The packet is sent to the crypto device for security 200protocol processing. The device will decrypt the packet and it will also 201optionally remove additional security headers from the packet. 202E.g. in case of IPsec, IPsec tunnel headers (if any), ESP/AH headers 203will be removed from the packet and the decrypted packet may contain 204plain data only. 205 206.. note:: 207 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. 211 212Encryption: The software will submit the packet to cryptodev as usual 213for encryption, the hardware device in this case will also add the relevant 214security protocol header along with encrypting the packet. The software 215should make sure that the buffer has required head room and tail room 216for any protocol header addition. 217 218.. note:: 219 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 222 overflow. 223 224.. code-block:: console 225 226 Egress Data Path 227 | 228 +--------|--------+ 229 | egress IPsec | 230 | | | 231 | +------V------+ | 232 | | SADB lookup | | <------ SA maps to cryptodev session 233 | +------|------+ | 234 | +------|------+ | 235 | | \--------------------\ 236 | | Crypto | | | <- Crypto processing through 237 | | /----------------\ | inline crypto PMD 238 | +------|------+ | | | 239 +--------V--------+ | | 240 | | | 241 +--------V--------+ | | create <-- SA is added to hw 242 | L2 Stack | | | inline using existing create 243 +--------|--------+ | | session sym session APIs 244 | | | | 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 250 | inline. 251 +--------|--------+ 252 | NIC | 253 +--------|--------+ 254 V 255 256PDCP Flow Diagram 257~~~~~~~~~~~~~~~~~ 258 259Based on 3GPP TS 36.323 Evolved Universal Terrestrial Radio Access (E-UTRA); 260Packet Data Convergence Protocol (PDCP) specification 261 262.. code-block:: c 263 264 Transmitting PDCP Entity Receiving PDCP Entity 265 | ^ 266 | +-----------|-----------+ 267 V | In order delivery and | 268 +---------|----------+ | Duplicate detection | 269 | Sequence Numbering | | (Data Plane only) | 270 +---------|----------+ +-----------|-----------+ 271 | | 272 +---------|----------+ +-----------|----------+ 273 | Header Compression*| | Header Decompression*| 274 | (Data-Plane only) | | (Data Plane only) | 275 +---------|----------+ +-----------|----------+ 276 | | 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 +---------|-----------+ +----------|----------+ 287 | | 288 +----------------->>----------------+ 289 290 291.. note:: 292 293 * Header Compression and decompression are not supported currently. 294 295Just like IPsec, in case of PDCP also header addition/deletion, cipher/ 296de-cipher, integrity protection/verification is done based on the action 297type chosen. 298 299Device Features and Capabilities 300--------------------------------- 301 302Device Capabilities For Security Operations 303~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 304 305The device (crypto or ethernet) capabilities which support security operations, 306are defined by the security action type, security protocol, protocol 307capabilities and corresponding crypto capabilities for security. For the full 308scope of the Security capability see definition of rte_security_capability 309structure in the *DPDK API Reference*. 310 311.. code-block:: c 312 313 struct rte_security_capability; 314 315Each driver (crypto or ethernet) defines its own private array of capabilities 316for the operations it supports. Below is an example of the capabilities for a 317PMD which supports the IPsec and PDCP protocol. 318 319.. code-block:: c 320 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, 325 .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, 329 .options = { 0 } 330 }, 331 .crypto_capabilities = pmd_capabilities 332 }, 333 { /* IPsec Lookaside Protocol offload ESP Tunnel Ingress */ 334 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL, 335 .protocol = RTE_SECURITY_PROTOCOL_IPSEC, 336 .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, 340 .options = { 0 } 341 }, 342 .crypto_capabilities = pmd_capabilities 343 }, 344 { /* PDCP Lookaside Protocol offload Data Plane */ 345 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL, 346 .protocol = RTE_SECURITY_PROTOCOL_PDCP, 347 .pdcp = { 348 .domain = RTE_SECURITY_PDCP_MODE_DATA, 349 .capa_flags = 0 350 }, 351 .crypto_capabilities = pmd_capabilities 352 }, 353 { /* PDCP Lookaside Protocol offload Control */ 354 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL, 355 .protocol = RTE_SECURITY_PROTOCOL_PDCP, 356 .pdcp = { 357 .domain = RTE_SECURITY_PDCP_MODE_CONTROL, 358 .capa_flags = 0 359 }, 360 .crypto_capabilities = pmd_capabilities 361 }, 362 { 363 .action = RTE_SECURITY_ACTION_TYPE_NONE 364 } 365 }; 366 static const struct rte_cryptodev_capabilities pmd_capabilities[] = { 367 { /* SHA1 HMAC */ 368 .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC, 369 .sym = { 370 .xform_type = RTE_CRYPTO_SYM_XFORM_AUTH, 371 .auth = { 372 .algo = RTE_CRYPTO_AUTH_SHA1_HMAC, 373 .block_size = 64, 374 .key_size = { 375 .min = 64, 376 .max = 64, 377 .increment = 0 378 }, 379 .digest_size = { 380 .min = 12, 381 .max = 12, 382 .increment = 0 383 }, 384 .aad_size = { 0 }, 385 .iv_size = { 0 } 386 } 387 } 388 }, 389 { /* AES CBC */ 390 .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC, 391 .sym = { 392 .xform_type = RTE_CRYPTO_SYM_XFORM_CIPHER, 393 .cipher = { 394 .algo = RTE_CRYPTO_CIPHER_AES_CBC, 395 .block_size = 16, 396 .key_size = { 397 .min = 16, 398 .max = 32, 399 .increment = 8 400 }, 401 .iv_size = { 402 .min = 16, 403 .max = 16, 404 .increment = 0 405 } 406 } 407 } 408 } 409 } 410 411 412Capabilities Discovery 413~~~~~~~~~~~~~~~~~~~~~~ 414 415Discovering the features and capabilities of a driver (crypto/ethernet) 416is achieved through the ``rte_security_capabilities_get()`` function. 417 418.. code-block:: c 419 420 const struct rte_security_capability *rte_security_capabilities_get(uint16_t id); 421 422This allows the user to query a specific driver and get all device 423security capabilities. It returns an array of ``rte_security_capability`` structures 424which contains all the capabilities for that device. 425 426Security Session Create/Free 427~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 428 429Security Sessions are created to store the immutable fields of a particular Security 430Association for a particular protocol which is defined by a security session 431configuration structure which is used in the operation processing of a packet flow. 432Sessions are used to manage protocol specific information as well as crypto parameters. 433Security sessions cache this immutable data in a optimal way for the underlying PMD 434and this allows further acceleration of the offload of Crypto workloads. 435 436The Security framework provides APIs to create and free sessions for crypto/ethernet 437devices, where sessions are mempool objects. It is the application's responsibility 438to create and manage the session mempools. The mempool object size should be able to 439accommodate the driver's private data of security session. 440 441Once the session mempools have been created, ``rte_security_session_create()`` 442is used to allocate and initialize a session for the required crypto/ethernet device. 443 444Session APIs need a parameter ``rte_security_ctx`` to identify the crypto/ethernet 445security 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`` 447(for ethernet port). 448 449Sessions already created can be updated with ``rte_security_session_update()``. 450 451When a session is no longer used, the user must call ``rte_security_session_destroy()`` 452to free the driver private session data and return the memory back to the mempool. 453 454For look aside protocol offload to hardware crypto device, the ``rte_crypto_op`` 455created by the application is attached to the security session by the API 456``rte_security_attach_session()``. 457 458For Inline Crypto and Inline protocol offload, device specific defined metadata is 459updated in the mbuf using ``rte_security_set_pkt_metadata()`` if 460``DEV_TX_OFFLOAD_SEC_NEED_MDATA`` is set. 461 462For inline protocol offloaded ingress traffic, the application can register a 463pointer, ``userdata`` , in the security session. When the packet is received, 464``rte_security_get_userdata()`` would return the userdata registered for the 465security session which processed the packet. 466 467.. note:: 468 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. 477 478Security session configuration 479~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 480 481Security Session configuration structure is defined as ``rte_security_session_conf`` 482 483.. code-block:: c 484 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 */ 490 union { 491 struct rte_security_ipsec_xform ipsec; 492 struct rte_security_macsec_xform macsec; 493 struct rte_security_pdcp_xform pdcp; 494 }; 495 /**< Configuration parameters for security session */ 496 struct rte_crypto_sym_xform *crypto_xform; 497 /**< Security Session Crypto Transformations */ 498 void *userdata; 499 /**< Application specific userdata to be saved with session */ 500 }; 501 502The configuration structure reuses the ``rte_crypto_sym_xform`` struct for crypto related 503configuration. The ``rte_security_session_action_type`` struct is used to specify whether the 504session is configured for Lookaside Protocol offload or Inline Crypto or Inline Protocol 505Offload. 506 507.. code-block:: c 508 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 */ 516 RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL, 517 /**< All security protocol processing is performed inline during 518 * transmission 519 */ 520 RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL, 521 /**< All security protocol processing including crypto is performed 522 * on a lookaside accelerator 523 */ 524 RTE_SECURITY_ACTION_TYPE_CPU_CRYPTO 525 /**< Similar to ACTION_TYPE_NONE but crypto processing for security 526 * protocol is processed synchronously by a CPU. 527 */ 528 }; 529 530The ``rte_security_session_protocol`` is defined as 531 532.. code-block:: c 533 534 enum rte_security_session_protocol { 535 RTE_SECURITY_PROTOCOL_IPSEC = 1, 536 /**< IPsec Protocol */ 537 RTE_SECURITY_PROTOCOL_MACSEC, 538 /**< MACSec Protocol */ 539 RTE_SECURITY_PROTOCOL_PDCP, 540 /**< PDCP Protocol */ 541 }; 542 543Currently the library defines configuration parameters for IPsec and PDCP only. 544For other protocols like MACSec, structures and enums are defined as place holders 545which will be updated in the future. 546 547IPsec related configuration parameters are defined in ``rte_security_ipsec_xform`` 548 549.. code-block:: c 550 551 struct rte_security_ipsec_xform { 552 uint32_t spi; 553 /**< SA security parameter index */ 554 uint32_t salt; 555 /**< SA salt */ 556 struct rte_security_ipsec_sa_options options; 557 /**< various SA options */ 558 enum rte_security_ipsec_sa_direction direction; 559 /**< IPsec SA Direction - Egress/Ingress */ 560 enum rte_security_ipsec_sa_protocol proto; 561 /**< IPsec SA Protocol - AH/ESP */ 562 enum rte_security_ipsec_sa_mode mode; 563 /**< IPsec SA Mode - transport/tunnel */ 564 struct rte_security_ipsec_tunnel_param tunnel; 565 /**< Tunnel parameters, NULL for transport mode */ 566 }; 567 568PDCP related configuration parameters are defined in ``rte_security_pdcp_xform`` 569 570.. code-block:: c 571 572 struct rte_security_pdcp_xform { 573 int8_t bearer; /**< PDCP bearer ID */ 574 /** Enable in order delivery, this field shall be set only if 575 * driver/HW is capable. See RTE_SECURITY_PDCP_ORDERING_CAP. 576 */ 577 uint8_t en_ordering; 578 /** Notify driver/HW to detect and remove duplicate packets. 579 * This field should be set only when driver/hw is capable. 580 * See RTE_SECURITY_PDCP_DUP_DETECT_CAP. 581 */ 582 uint8_t remove_duplicates; 583 /** PDCP mode of operation: Control or data */ 584 enum rte_security_pdcp_domain domain; 585 /** PDCP Frame Direction 0:UL 1:DL */ 586 enum rte_security_pdcp_direction pkt_dir; 587 /** Sequence number size, 5/7/12/15/18 */ 588 enum rte_security_pdcp_sn_size sn_size; 589 /** Starting Hyper Frame Number to be used together with the SN 590 * from the PDCP frames 591 */ 592 uint32_t hfn; 593 /** HFN Threshold for key renegotiation */ 594 uint32_t hfn_threshold; 595 }; 596 597 598Security API 599~~~~~~~~~~~~ 600 601The rte_security Library API is described in the *DPDK API Reference* document. 602 603Flow based Security Session 604~~~~~~~~~~~~~~~~~~~~~~~~~~~ 605 606In the case of NIC based offloads, the security session specified in the 607'rte_flow_action_security' must be created on the same port as the 608flow action that is being specified. 609 610The ingress/egress flow attribute should match that specified in the security 611session if the security session supports the definition of the direction. 612 613Multiple flows can be configured to use the same security session. For 614example if the security session specifies an egress IPsec SA, then multiple 615flows can be specified to that SA. In the case of an ingress IPsec SA then 616it is only valid to have a single flow to map to that security session. 617 618.. code-block:: console 619 620 Configuration Path 621 | 622 +--------|--------+ 623 | Add/Remove | 624 | IPsec SA | <------ Build security flow action of 625 | | | ipsec transform 626 |--------|--------| 627 | 628 +--------V--------+ 629 | Flow API | 630 +--------|--------+ 631 | 632 +--------V--------+ 633 | | 634 | NIC PMD | <------ Add/Remove SA to/from hw context 635 | | 636 +--------|--------+ 637 | 638 +--------|--------+ 639 | HW ACCELERATED | 640 | NIC | 641 | | 642 +--------|--------+ 643 644* Add/Delete SA flow: 645 To add a new inline SA construct a rte_flow_item for Ethernet + IP + ESP 646 using the SA selectors and the ``rte_crypto_ipsec_xform`` as the ``rte_flow_action``. 647 Note that any rte_flow_items may be empty, which means it is not checked. 648 649.. code-block:: console 650 651 In its most basic form, IPsec flow specification is as follows: 652 +-------+ +----------+ +--------+ +-----+ 653 | Eth | -> | IP4/6 | -> | ESP | -> | END | 654 +-------+ +----------+ +--------+ +-----+ 655 656 However, the API can represent, IPsec crypto offload with any encapsulation: 657 +-------+ +--------+ +-----+ 658 | Eth | -> ... -> | ESP | -> | END | 659 +-------+ +--------+ +-----+ 660