1.. SPDX-License-Identifier: BSD-3-Clause 2 Copyright 2017,2020-2021 NXP 3 4Security Library 5================ 6 7The security library provides a framework for management and provisioning 8of security protocol operations offloaded to hardware based devices. The 9library defines generic APIs to create and free security sessions which can 10support full protocol offload as well as inline crypto operation with 11NIC or crypto devices. 12 13The security protocols are discussed in the :doc:`../howto/security` guide. 14 15Design Principles 16----------------- 17 18The security library provides an additional offload capability to an existing 19crypto device and/or ethernet device. 20 21.. code-block:: console 22 23 +---------------+ 24 | rte_security | 25 +---------------+ 26 \ / 27 +-----------+ +--------------+ 28 | NIC PMD | | CRYPTO PMD | 29 +-----------+ +--------------+ 30 31.. note:: 32 33 Currently, the security library does not support the case of multi-process. 34 It will be updated in the future releases. 35 36The supported offload types are explained in the sections below. 37 38Inline Crypto 39~~~~~~~~~~~~~ 40 41RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO: 42The crypto processing for security protocol (e.g. IPsec) is processed 43inline during receive and transmission on NIC port. The flow based 44security action should be configured on the port. 45 46Ingress Data path - The packet is decrypted in RX path and relevant 47crypto status is set in Rx descriptors. After the successful inline 48crypto processing the packet is presented to host as a regular Rx packet 49however all security protocol related headers are still attached to the 50packet. e.g. In case of IPsec, the IPsec tunnel headers (if any), 51ESP/AH headers will remain in the packet but the received packet 52contains the decrypted data where the encrypted data was when the packet 53arrived. The driver Rx path check the descriptors and based on the 54crypto status sets additional flags in the rte_mbuf.ol_flags field. 55 56.. note:: 57 58 The underlying device may not support crypto processing for all ingress packet 59 matching to a particular flow (e.g. fragmented packets), such packets will 60 be passed as encrypted packets. It is the responsibility of application to 61 process such encrypted packets using other crypto driver instance. 62 63Egress Data path - The software prepares the egress packet by adding 64relevant security protocol headers. Only the data will not be 65encrypted by the software. The driver will accordingly configure the 66tx descriptors. The hardware device will encrypt the data before sending the 67packet out. 68 69.. note:: 70 71 The underlying device may support post encryption TSO. 72 73.. code-block:: console 74 75 Egress Data Path 76 | 77 +--------|--------+ 78 | egress IPsec | 79 | | | 80 | +------V------+ | 81 | | SADB lookup | | 82 | +------|------+ | 83 | +------V------+ | 84 | | Tunnel | | <------ Add tunnel header to packet 85 | +------|------+ | 86 | +------V------+ | 87 | | ESP | | <------ Add ESP header without trailer to packet 88 | | | | <------ Mark packet to be offloaded, add trailer 89 | +------|------+ | meta-data to mbuf 90 +--------V--------+ 91 | 92 +--------V--------+ 93 | L2 Stack | 94 +--------|--------+ 95 | 96 +--------V--------+ 97 | | 98 | NIC PMD | <------ Set hw context for inline crypto offload 99 | | 100 +--------|--------+ 101 | 102 +--------|--------+ 103 | HW ACCELERATED | <------ Packet Encryption and 104 | NIC | Authentication happens inline 105 | | 106 +-----------------+ 107 108 109Inline protocol offload 110~~~~~~~~~~~~~~~~~~~~~~~ 111 112RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL: 113The crypto and protocol processing for security protocol (e.g. IPsec) 114is processed inline during receive and transmission. The flow based 115security action should be configured on the port. 116 117Ingress Data path - The packet is decrypted in the RX path and relevant 118crypto status is set in the Rx descriptors. After the successful inline 119crypto processing the packet is presented to the host as a regular Rx packet 120but all security protocol related headers are optionally removed from the 121packet. e.g. in the case of IPsec, the IPsec tunnel headers (if any), 122ESP/AH headers will be removed from the packet and the received packet 123will contains the decrypted packet only. The driver Rx path checks the 124descriptors and based on the crypto status sets additional flags in 125``rte_mbuf.ol_flags`` field. The driver would also set device-specific 126metadata in ``RTE_SECURITY_DYNFIELD_NAME`` field. 127This will allow the application to identify the security processing 128done 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. The software should also make sure that L2 header contents 148are updated with the final L2 header which is expected post IPsec processing as 149the IPsec offload will only update L3 and above in egress path. 150 151 152.. note:: 153 154 The underlying device will manage state information required for egress 155 processing. E.g. in case of IPsec, the seq number will be added to the 156 packet, however the device shall provide indication when the sequence number 157 is about to overflow. The underlying device may support post encryption TSO. 158 159.. code-block:: console 160 161 Egress Data Path 162 | 163 +--------|--------+ 164 | egress IPsec | 165 | | | 166 | +------V------+ | 167 | | SADB lookup | | 168 | +------|------+ | 169 | +------V------+ | 170 | | Desc | | <------ Mark packet to be offloaded 171 | +------|------+ | 172 +--------V--------+ 173 | 174 +--------V--------+ 175 | L2 Stack | 176 +--------|--------+ 177 | 178 +--------V--------+ 179 | | 180 | NIC PMD | <------ Set hw context for inline crypto offload 181 | | 182 +--------|--------+ 183 | 184 +--------|--------+ 185 | HW ACCELERATED | <------ Add tunnel, ESP header etc header to 186 | NIC | packet. Packet Encryption and 187 | | Authentication happens inline. 188 +-----------------+ 189 190 191Lookaside protocol offload 192~~~~~~~~~~~~~~~~~~~~~~~~~~ 193 194RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL: 195This extends librte_cryptodev to support the programming of IPsec 196Security Association (SA) as part of a crypto session creation including 197the definition. In addition to standard crypto processing, as defined by 198the cryptodev, the security protocol processing is also offloaded to the 199crypto device. 200 201Decryption: The packet is sent to the crypto device for security 202protocol processing. The device will decrypt the packet and it will also 203optionally remove additional security headers from the packet. 204E.g. in case of IPsec, IPsec tunnel headers (if any), ESP/AH headers 205will be removed from the packet and the decrypted packet may contain 206plain data only. 207 208.. note:: 209 210 In case of IPsec the device may internally manage anti-replay etc. 211 It will provide a configuration option for anti-replay behavior i.e. to drop 212 the packets or pass them to driver with error flags set in descriptor. 213 214Encryption: The software will submit the packet to cryptodev as usual 215for encryption, the hardware device in this case will also add the relevant 216security protocol header along with encrypting the packet. The software 217should make sure that the buffer has required head room and tail room 218for any protocol header addition. 219 220.. note:: 221 222 In the case of IPsec, the seq number will be added to the packet, 223 It shall provide an indication when the sequence number is about to 224 overflow. 225 226.. code-block:: console 227 228 Egress Data Path 229 | 230 +--------|--------+ 231 | egress IPsec | 232 | | | 233 | +------V------+ | 234 | | SADB lookup | | <------ SA maps to cryptodev session 235 | +------|------+ | 236 | +------|------+ | 237 | | \--------------------\ 238 | | Crypto | | | <- Crypto processing through 239 | | /----------------\ | inline crypto PMD 240 | +------|------+ | | | 241 +--------V--------+ | | 242 | | | 243 +--------V--------+ | | create <-- SA is added to hw 244 | L2 Stack | | | inline using existing create 245 +--------|--------+ | | session sym session APIs 246 | | | | 247 +--------V--------+ +---|---|----V---+ 248 | | | \---/ | | <--- Add tunnel, ESP header etc 249 | NIC PMD | | INLINE | | header to packet.Packet 250 | | | CRYPTO PMD | | Encryption/Decryption and 251 +--------|--------+ +----------------+ Authentication happens 252 | inline. 253 +--------|--------+ 254 | NIC | 255 +--------|--------+ 256 V 257 258PDCP Flow Diagram 259~~~~~~~~~~~~~~~~~ 260 261Based on 3GPP TS 36.323 Evolved Universal Terrestrial Radio Access (E-UTRA); 262Packet Data Convergence Protocol (PDCP) specification 263 264.. code-block:: c 265 266 Transmitting PDCP Entity Receiving PDCP Entity 267 | ^ 268 | +-----------|-----------+ 269 V | In order delivery and | 270 +---------|----------+ | Duplicate detection | 271 | Sequence Numbering | | (Data Plane only) | 272 +---------|----------+ +-----------|-----------+ 273 | | 274 +---------|----------+ +-----------|----------+ 275 | Header Compression*| | Header Decompression*| 276 | (Data-Plane only) | | (Data Plane only) | 277 +---------|----------+ +-----------|----------+ 278 | | 279 +---------|-----------+ +-----------|----------+ 280 | Integrity Protection| |Integrity Verification| 281 | (Control Plane only)| | (Control Plane only) | 282 +---------|-----------+ +-----------|----------+ 283 +---------|-----------+ +----------|----------+ 284 | Ciphering | | Deciphering | 285 +---------|-----------+ +----------|----------+ 286 +---------|-----------+ +----------|----------+ 287 | Add PDCP header | | Remove PDCP Header | 288 +---------|-----------+ +----------|----------+ 289 | | 290 +----------------->>----------------+ 291 292 293.. note:: 294 295 * Header Compression and decompression are not supported currently. 296 297Just like IPsec, in case of PDCP also header addition/deletion, cipher/ 298de-cipher, integrity protection/verification is done based on the action 299type chosen. 300 301DOCSIS Protocol 302~~~~~~~~~~~~~~~ 303 304The Data Over Cable Service Interface Specification (DOCSIS) support comprises 305the combination of encryption/decryption and CRC generation/verification, for 306use in a DOCSIS-MAC pipeline. 307 308.. code-block:: c 309 310 311 Downlink Uplink 312 -------- ------ 313 314 Ethernet frame Ethernet frame 315 from core network to core network 316 | ^ 317 ~ | 318 | ~ ----+ 319 V | | 320 +---------|----------+ +----------|---------+ | 321 | CRC generation | | CRC verification | | 322 +---------|----------+ +----------|---------+ | combined 323 | | > Crypto + CRC 324 +---------|----------+ +----------|---------+ | 325 | Encryption | | Decryption | | 326 +---------|----------+ +----------|---------+ | 327 | ^ | 328 ~ | ----+ 329 | ~ 330 V | 331 DOCSIS frame DOCSIS frame 332 to Cable Modem from Cable Modem 333 334The encryption/decryption is a combination of CBC and CFB modes using either AES 335or DES algorithms as specified in the DOCSIS Security Specification (from DPDK 336lib_rtecryptodev perspective, these are RTE_CRYPTO_CIPHER_AES_DOCSISBPI and 337RTE_CRYPTO_CIPHER_DES_DOCSISBPI). 338 339The CRC is Ethernet CRC-32 as specified in Ethernet/[ISO/IEC 8802-3]. 340 341.. note:: 342 343 * The offset and length of data for which CRC needs to be computed are 344 specified via the auth offset and length fields of the rte_crypto_sym_op. 345 * Other DOCSIS protocol functionality such as Header Checksum (HCS) 346 calculation may be added in the future. 347 348MACSEC Protocol 349~~~~~~~~~~~~~~~ 350 351Media Access Control security (MACsec) provides point-to-point security 352on Ethernet links and is defined by IEEE standard 802.1AE. 353MACsec secures an Ethernet link for almost all traffic, 354including frames from the Link Layer Discovery Protocol (LLDP), 355Link Aggregation Control Protocol (LACP), 356Dynamic Host Configuration Protocol (DHCP), 357Address Resolution Protocol (ARP), 358and other protocols that are not typically secured on an Ethernet link 359because of limitations with other security solutions. 360 361.. code-block:: c 362 363 Receive Transmit 364 ------- -------- 365 366 Ethernet frame Ethernet frame 367 from network towards network 368 | ^ 369 ~ | 370 | ~ 371 V | 372 +-----------------------+ +------------------+ +-------------------------+ 373 | Secure Frame Verify | | Cipher Suite(SA) | | Secure Frame Generation | 374 +-----------------------+<-----+------------------+----->+-------------------------+ 375 | SecTAG + ICV remove | | SECY | SC | | SecTAG + ICV Added | 376 +---+-------------------+ +------------------+ +-------------------------+ 377 | ^ 378 | | 379 V | 380 Packet to Core/App Packet from Core/App 381 382 383 384To configure MACsec on an inline NIC device or a lookaside crypto device, 385a security association (SA) and a secure channel (SC) are created 386before creating rte_security session. 387 388SA is created using API ``rte_security_macsec_sa_create`` 389which allows setting SA keys, salt, SSCI, packet number (PN) into the PMD, 390and the API returns a handle which can be used to map it with a secure channel, 391using the API ``rte_security_macsec_sc_create``. 392Same SAs can be used for multiple SCs. 393The Rx SC will need a set of 4 SAs for each of the association numbers (AN). 394For Tx SC a single SA is set which will be used by hardware to process the packet. 395 396The API ``rte_security_macsec_sc_create`` returns a handle for SC, 397and this handle is set in ``rte_security_macsec_xform`` 398to create a MACsec session using ``rte_security_session_create``. 399 400TLS-Record Protocol 401~~~~~~~~~~~~~~~~~~~ 402 403The Transport Layer Protocol provides communications security over the Internet. 404The protocol allows client/server applications to communicate in a way 405that is designed to prevent eavesdropping, tampering, or message forgery. 406 407TLS protocol is composed of two layers: the TLS Record Protocol and the TLS Handshake Protocol. 408At the lowest level, layered on top of some reliable transport protocol (e.g., TCP), 409is the TLS Record Protocol. 410The TLS Record Protocol provides connection security that has two basic properties: 411 412 - The connection is private. 413 Symmetric cryptography is used for data encryption (e.g., AES, DES, etc.). 414 The keys for this symmetric encryption are generated uniquely 415 for each connection and are based on a secret negotiated during TLS Handshake Protocol. 416 The Record Protocol can also be used without encryption. 417 418 - The connection is reliable. 419 Message transport includes a message integrity check using a keyed MAC. 420 Secure hash functions (e.g., SHA-1, etc.) are used for MAC computations. 421 The Record Protocol can operate without a MAC when it is being used as a transport 422 for negotiating security parameters by another protocol. 423 424.. code-block:: c 425 426 Record Write Record Read 427 ------------ ----------- 428 429 TLSPlaintext TLSCiphertext 430 | | 431 ~ ~ 432 | | 433 V V 434 +----------|-----------+ +----------|-----------+ 435 | Generate sequence no.| | Generate sequence no.| 436 +----------|-----------+ +----------------------+ 437 | | AR check (DTLS) | 438 +----------|-----------+ +----------|-----------+ 439 | Insert TLS header | | 440 | & trailer. | +----------|-----------+ 441 | (including padding) | | Decrypt & MAC verify | 442 +----------|-----------+ +----------|-----------+ 443 | | 444 +---------|-----------+ +----------|-----------+ 445 | MAC generate & | | Remove TLS header | 446 | Encrypt | | & trailer. | 447 +---------|-----------+ | (including padding) | 448 | +----------|-----------+ 449 | | 450 ~ ~ 451 | | 452 V V 453 TLSCiphertext TLSPlaintext 454 455TLS and DTLS header formation (in record write operation) 456would depend on type of content. 457It is a per packet variable and would need to be handled by the same session. 458Application may pass this info to a cryptodev performing lookaside protocol offload 459by passing the same in ``rte_crypto_op.param1``. 460 461In record read operation, application is required to preserve any info 462it may need from the TLS/DTLS header (such as content type and sequence number) 463as the cryptodev would remove the header and padding 464as part of the lookaside protocol processing. 465With TLS 1.3, the actual content type is part of the trailer (before padding) 466and would be stripped by the PMD. 467For applications that may need this info, 468PMD would return the value in ``rte_crypto_op.param1`` field. 469 470Supported Versions 471^^^^^^^^^^^^^^^^^^ 472 473* TLS 1.2 474* TLS 1.3 475* DTLS 1.2 476 477Device Features and Capabilities 478--------------------------------- 479 480Device Capabilities For Security Operations 481~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 482 483The device (crypto or ethernet) capabilities which support security operations, 484are defined by the security action type, security protocol, protocol 485capabilities and corresponding crypto capabilities for security. For the full 486scope of the Security capability see definition of rte_security_capability 487structure in the *DPDK API Reference*. 488 489.. code-block:: c 490 491 struct rte_security_capability; 492 493Each driver (crypto or ethernet) defines its own private array of capabilities 494for the operations it supports. Below is an example of the capabilities for a 495PMD which supports the IPsec and PDCP protocol. 496 497.. code-block:: c 498 499 static const struct rte_security_capability pmd_security_capabilities[] = { 500 { /* IPsec Lookaside Protocol offload ESP Tunnel Egress */ 501 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL, 502 .protocol = RTE_SECURITY_PROTOCOL_IPSEC, 503 .ipsec = { 504 .proto = RTE_SECURITY_IPSEC_SA_PROTO_ESP, 505 .mode = RTE_SECURITY_IPSEC_SA_MODE_TUNNEL, 506 .direction = RTE_SECURITY_IPSEC_SA_DIR_EGRESS, 507 .options = { 0 } 508 }, 509 .crypto_capabilities = pmd_capabilities 510 }, 511 { /* IPsec Lookaside Protocol offload ESP Tunnel Ingress */ 512 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL, 513 .protocol = RTE_SECURITY_PROTOCOL_IPSEC, 514 .ipsec = { 515 .proto = RTE_SECURITY_IPSEC_SA_PROTO_ESP, 516 .mode = RTE_SECURITY_IPSEC_SA_MODE_TUNNEL, 517 .direction = RTE_SECURITY_IPSEC_SA_DIR_INGRESS, 518 .options = { 0 } 519 }, 520 .crypto_capabilities = pmd_capabilities 521 }, 522 { /* PDCP Lookaside Protocol offload Data Plane */ 523 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL, 524 .protocol = RTE_SECURITY_PROTOCOL_PDCP, 525 .pdcp = { 526 .domain = RTE_SECURITY_PDCP_MODE_DATA, 527 .capa_flags = 0 528 }, 529 .crypto_capabilities = pmd_capabilities 530 }, 531 { /* PDCP Lookaside Protocol offload Control */ 532 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL, 533 .protocol = RTE_SECURITY_PROTOCOL_PDCP, 534 .pdcp = { 535 .domain = RTE_SECURITY_PDCP_MODE_CONTROL, 536 .capa_flags = 0 537 }, 538 .crypto_capabilities = pmd_capabilities 539 }, 540 { /* PDCP Lookaside Protocol offload short MAC-I */ 541 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL, 542 .protocol = RTE_SECURITY_PROTOCOL_PDCP, 543 .pdcp = { 544 .domain = RTE_SECURITY_PDCP_MODE_SHORT_MAC, 545 .capa_flags = 0 546 }, 547 .crypto_capabilities = pmd_capabilities 548 }, 549 { 550 .action = RTE_SECURITY_ACTION_TYPE_NONE 551 } 552 }; 553 static const struct rte_cryptodev_capabilities pmd_capabilities[] = { 554 { /* SHA1 HMAC */ 555 .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC, 556 .sym = { 557 .xform_type = RTE_CRYPTO_SYM_XFORM_AUTH, 558 .auth = { 559 .algo = RTE_CRYPTO_AUTH_SHA1_HMAC, 560 .block_size = 64, 561 .key_size = { 562 .min = 64, 563 .max = 64, 564 .increment = 0 565 }, 566 .digest_size = { 567 .min = 12, 568 .max = 12, 569 .increment = 0 570 }, 571 .aad_size = { 0 }, 572 .iv_size = { 0 } 573 } 574 } 575 }, 576 { /* AES CBC */ 577 .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC, 578 .sym = { 579 .xform_type = RTE_CRYPTO_SYM_XFORM_CIPHER, 580 .cipher = { 581 .algo = RTE_CRYPTO_CIPHER_AES_CBC, 582 .block_size = 16, 583 .key_size = { 584 .min = 16, 585 .max = 32, 586 .increment = 8 587 }, 588 .iv_size = { 589 .min = 16, 590 .max = 16, 591 .increment = 0 592 } 593 } 594 } 595 } 596 } 597 598Below is an example of the capabilities for a PMD which supports the DOCSIS 599protocol. 600 601.. code-block:: c 602 603 static const struct rte_security_capability pmd_security_capabilities[] = { 604 { /* DOCSIS Uplink */ 605 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL, 606 .protocol = RTE_SECURITY_PROTOCOL_DOCSIS, 607 .docsis = { 608 .direction = RTE_SECURITY_DOCSIS_UPLINK 609 }, 610 .crypto_capabilities = pmd_capabilities 611 }, 612 { /* DOCSIS Downlink */ 613 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL, 614 .protocol = RTE_SECURITY_PROTOCOL_DOCSIS, 615 .docsis = { 616 .direction = RTE_SECURITY_DOCSIS_DOWNLINK 617 }, 618 .crypto_capabilities = pmd_capabilities 619 }, 620 { 621 .action = RTE_SECURITY_ACTION_TYPE_NONE 622 } 623 }; 624 static const struct rte_cryptodev_capabilities pmd_capabilities[] = { 625 { /* AES DOCSIS BPI */ 626 .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC, 627 .sym = { 628 .xform_type = RTE_CRYPTO_SYM_XFORM_CIPHER, 629 .cipher = { 630 .algo = RTE_CRYPTO_CIPHER_AES_DOCSISBPI, 631 .block_size = 16, 632 .key_size = { 633 .min = 16, 634 .max = 32, 635 .increment = 16 636 }, 637 .iv_size = { 638 .min = 16, 639 .max = 16, 640 .increment = 0 641 } 642 } 643 } 644 }, 645 646 RTE_CRYPTODEV_END_OF_CAPABILITIES_LIST() 647 }; 648 649Below is the example PMD capability for MACsec 650 651.. code-block:: c 652 653 static const struct rte_security_capability pmd_security_capabilities[] = { 654 { 655 .action = RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL, 656 .protocol = RTE_SECURITY_PROTOCOL_MACSEC, 657 .macsec = { 658 .mtu = 1500, 659 .alg = RTE_SECURITY_MACSEC_ALG_GCM_128, 660 .max_nb_sc = 64, 661 .max_nb_sa = 128, 662 .max_nb_sess = 64, 663 .replay_win_sz = 4096, 664 .relative_sectag_insert = 1, 665 .fixed_sectag_insert = 1, 666 .icv_include_da_sa = 1, 667 .ctrl_port_enable = 1, 668 .preserve_sectag = 1, 669 .preserve_icv = 1, 670 .validate_frames = 1, 671 .re_key = 1, 672 .anti_replay = 1, 673 }, 674 .crypto_capabilities = NULL, 675 }, 676 }; 677 678Capabilities Discovery 679~~~~~~~~~~~~~~~~~~~~~~ 680 681Discovering the features and capabilities of a driver (crypto/ethernet) 682is achieved through the ``rte_security_capabilities_get()`` function. 683 684.. code-block:: c 685 686 const struct rte_security_capability *rte_security_capabilities_get(uint16_t id); 687 688This allows the user to query a specific driver and get all device 689security capabilities. It returns an array of ``rte_security_capability`` structures 690which contains all the capabilities for that device. 691 692Security Session Create/Free 693~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 694 695Security Sessions are created to store the immutable fields of a particular Security 696Association for a particular protocol which is defined by a security session 697configuration structure which is used in the operation processing of a packet flow. 698Sessions are used to manage protocol specific information as well as crypto parameters. 699Security sessions cache this immutable data in a optimal way for the underlying PMD 700and this allows further acceleration of the offload of Crypto workloads. 701 702The Security framework provides APIs to create and free sessions for crypto/ethernet 703devices, where sessions are mempool objects. It is the application's responsibility 704to create and manage two session mempools - one for session and other for session 705private data. The private session data mempool object size should be able to 706accommodate the driver's private data of security session. The application can get 707the size of session private data using API ``rte_security_session_get_size``. 708And the session mempool object size should be enough to accommodate 709``rte_security_session``. 710 711Once the session mempools have been created, ``rte_security_session_create()`` 712is used to allocate and initialize a session for the required crypto/ethernet device. 713 714Session APIs need an opaque handle to identify the crypto/ethernet 715security ops. This parameter can be retrieved using the APIs 716``rte_cryptodev_get_sec_ctx()`` (for crypto device) or ``rte_eth_dev_get_sec_ctx`` 717(for ethernet port). 718 719Sessions already created can be updated with ``rte_security_session_update()``. 720 721When a session is no longer used, the user must call ``rte_security_session_destroy()`` 722to free the driver private session data and return the memory back to the mempool. 723 724For look aside protocol offload to hardware crypto device, the ``rte_crypto_op`` 725created by the application is attached to the security session by the API 726``rte_security_attach_session()``. 727 728For Inline Crypto and Inline protocol offload, device specific defined metadata is 729updated in the mbuf using ``rte_security_set_pkt_metadata()`` if 730``RTE_ETH_TX_OFFLOAD_SEC_NEED_MDATA`` is set. 731 732.. note:: 733 734 In case of inline processed packets, ``RTE_SECURITY_DYNFIELD_NAME`` field 735 would be used by the driver to relay information on the security processing 736 associated with the packet. In ingress, the driver would set this in Rx 737 path while in egress, ``rte_security_set_pkt_metadata()`` would perform a 738 similar operation. The application is expected not to modify the field 739 when it has relevant info. For ingress, this device-specific 64 bit value 740 is required to derive other information (like userdata), required for 741 identifying the security processing done on the packet. 742 743Security session configuration 744~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 745 746Security Session configuration structure is defined as ``rte_security_session_conf`` 747 748.. literalinclude:: ../../../lib/security/rte_security.h 749 :language: c 750 :start-after: Structure rte_security_session_conf 8< 751 :end-before: >8 End of structure rte_security_session_conf. 752 753The configuration structure reuses the ``rte_crypto_sym_xform`` struct for crypto related 754configuration. The ``rte_security_session_action_type`` struct is used to specify whether the 755session is configured for Lookaside Protocol offload or Inline Crypto or Inline Protocol 756Offload. 757 758.. literalinclude:: ../../../lib/security/rte_security.h 759 :language: c 760 :start-after: Enumeration of rte_security_session_action_type 8< 761 :end-before: >8 End enumeration of rte_security_session_action_type. 762 763The ``rte_security_session_protocol`` is defined as 764 765.. literalinclude:: ../../../lib/security/rte_security.h 766 :language: c 767 :start-after: Enumeration of rte_security_session_protocol 8< 768 :end-before: >8 End enumeration of rte_security_session_protocol. 769 770IPsec related configuration parameters are defined in ``rte_security_ipsec_xform`` 771 772MACsec related configuration parameters are defined in ``rte_security_macsec_xform`` 773 774PDCP related configuration parameters are defined in ``rte_security_pdcp_xform`` 775 776DOCSIS related configuration parameters are defined in ``rte_security_docsis_xform`` 777 778TLS record related configuration parameters are defined in ``rte_security_tls_record_xform`` 779 780 781Security API 782~~~~~~~~~~~~ 783 784The rte_security Library API is described in the *DPDK API Reference* document. 785 786Flow based Security Session 787~~~~~~~~~~~~~~~~~~~~~~~~~~~ 788 789In the case of NIC based offloads, the security session specified in the 790'rte_flow_action_security' must be created on the same port as the 791flow action that is being specified. 792 793The ingress/egress flow attribute should match that specified in the security 794session if the security session supports the definition of the direction. 795 796Multiple flows can be configured to use the same security session. For 797example if the security session specifies an egress IPsec/MACsec SA, then multiple 798flows can be specified to that SA. In the case of an ingress IPsec SA then 799it is only valid to have a single flow to map to that security session. 800 801.. code-block:: console 802 803 Configuration Path 804 | 805 +--------|--------+ 806 | Add/Remove | 807 | IPsec/MACsec SA | <------ Build security flow action of 808 | | | IPsec/MACsec transform 809 |--------|--------| 810 | 811 +--------V--------+ 812 | Flow API | 813 +--------|--------+ 814 | 815 +--------V--------+ 816 | | 817 | NIC PMD | <------ Add/Remove SA to/from hw context 818 | | 819 +--------|--------+ 820 | 821 +--------|--------+ 822 | HW ACCELERATED | 823 | NIC | 824 | | 825 +--------|--------+ 826 827* Add/Delete IPsec SA flow: 828 To add a new inline SA construct a rte_flow_item for Ethernet + IP + ESP 829 using the SA selectors and the ``rte_security_ipsec_xform`` as the ``rte_flow_action``. 830 Note that any rte_flow_items may be empty, which means it is not checked. 831 832.. code-block:: console 833 834 In its most basic form, IPsec flow specification is as follows: 835 +-------+ +----------+ +--------+ +-----+ 836 | Eth | -> | IP4/6 | -> | ESP | -> | END | 837 +-------+ +----------+ +--------+ +-----+ 838 839 However, the API can represent, IPsec crypto offload with any encapsulation: 840 +-------+ +--------+ +-----+ 841 | Eth | -> ... -> | ESP | -> | END | 842 +-------+ +--------+ +-----+ 843 844* Add/Delete MACsec SA flow: 845 To add a new inline SA construct a rte_flow_item for Ethernet + SecTAG 846 using the SA selectors and the ``rte_security_macsec_xform`` as the ``rte_flow_action``. 847 Note that any rte_flow_items may be empty, which means it is not checked. 848 849.. code-block:: console 850 851 In its most basic form, MACsec flow specification is as follows: 852 +-------+ +----------+ +-----+ 853 | Eth | -> | SecTag | -> | END | 854 +-------+ +----------+ +-----+ 855 856 However, the API can represent, MACsec offload with any encapsulation: 857 +-------+ +--------+ +-----+ 858 | Eth | -> ... -> | SecTag | -> | END | 859 +-------+ +--------+ +-----+ 860 861 862Telemetry support 863----------------- 864 865The Security library has support for displaying Crypto device information 866with respect to its Security capabilities. Telemetry commands that can be used 867are shown below. 868 869#. Get the list of available Crypto devices by ID, that supports Security features:: 870 871 --> /security/cryptodev/list 872 {"/security/cryptodev/list": [0, 1, 2, 3]} 873 874#. Get the security capabilities of a Crypto device:: 875 876 --> /security/cryptodev/sec_caps,0 877 {"/security/cryptodev/sec_caps": {"sec_caps": [<array of serialized bytes of 878 capabilities>], "sec_caps_n": <number of capabilities>}} 879 880 #. Get the security crypto capabilities of a Crypto device:: 881 882 --> /security/cryptodev/crypto_caps,0,0 883 {"/security/cryptodev/crypto_caps": {"crypto_caps": [<array of serialized bytes of 884 capabilities>], "crypto_caps_n": <number of capabilities>}} 885 886For more information on how to use the Telemetry interface, see 887the :doc:`../howto/telemetry`. 888