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