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. 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 348Device Features and Capabilities 349--------------------------------- 350 351Device Capabilities For Security Operations 352~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 353 354The device (crypto or ethernet) capabilities which support security operations, 355are defined by the security action type, security protocol, protocol 356capabilities and corresponding crypto capabilities for security. For the full 357scope of the Security capability see definition of rte_security_capability 358structure in the *DPDK API Reference*. 359 360.. code-block:: c 361 362 struct rte_security_capability; 363 364Each driver (crypto or ethernet) defines its own private array of capabilities 365for the operations it supports. Below is an example of the capabilities for a 366PMD which supports the IPsec and PDCP protocol. 367 368.. code-block:: c 369 370 static const struct rte_security_capability pmd_security_capabilities[] = { 371 { /* IPsec Lookaside Protocol offload ESP Tunnel Egress */ 372 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL, 373 .protocol = RTE_SECURITY_PROTOCOL_IPSEC, 374 .ipsec = { 375 .proto = RTE_SECURITY_IPSEC_SA_PROTO_ESP, 376 .mode = RTE_SECURITY_IPSEC_SA_MODE_TUNNEL, 377 .direction = RTE_SECURITY_IPSEC_SA_DIR_EGRESS, 378 .options = { 0 } 379 }, 380 .crypto_capabilities = pmd_capabilities 381 }, 382 { /* IPsec Lookaside Protocol offload ESP Tunnel Ingress */ 383 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL, 384 .protocol = RTE_SECURITY_PROTOCOL_IPSEC, 385 .ipsec = { 386 .proto = RTE_SECURITY_IPSEC_SA_PROTO_ESP, 387 .mode = RTE_SECURITY_IPSEC_SA_MODE_TUNNEL, 388 .direction = RTE_SECURITY_IPSEC_SA_DIR_INGRESS, 389 .options = { 0 } 390 }, 391 .crypto_capabilities = pmd_capabilities 392 }, 393 { /* PDCP Lookaside Protocol offload Data Plane */ 394 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL, 395 .protocol = RTE_SECURITY_PROTOCOL_PDCP, 396 .pdcp = { 397 .domain = RTE_SECURITY_PDCP_MODE_DATA, 398 .capa_flags = 0 399 }, 400 .crypto_capabilities = pmd_capabilities 401 }, 402 { /* PDCP Lookaside Protocol offload Control */ 403 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL, 404 .protocol = RTE_SECURITY_PROTOCOL_PDCP, 405 .pdcp = { 406 .domain = RTE_SECURITY_PDCP_MODE_CONTROL, 407 .capa_flags = 0 408 }, 409 .crypto_capabilities = pmd_capabilities 410 }, 411 { /* PDCP Lookaside Protocol offload short MAC-I */ 412 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL, 413 .protocol = RTE_SECURITY_PROTOCOL_PDCP, 414 .pdcp = { 415 .domain = RTE_SECURITY_PDCP_MODE_SHORT_MAC, 416 .capa_flags = 0 417 }, 418 .crypto_capabilities = pmd_capabilities 419 }, 420 { 421 .action = RTE_SECURITY_ACTION_TYPE_NONE 422 } 423 }; 424 static const struct rte_cryptodev_capabilities pmd_capabilities[] = { 425 { /* SHA1 HMAC */ 426 .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC, 427 .sym = { 428 .xform_type = RTE_CRYPTO_SYM_XFORM_AUTH, 429 .auth = { 430 .algo = RTE_CRYPTO_AUTH_SHA1_HMAC, 431 .block_size = 64, 432 .key_size = { 433 .min = 64, 434 .max = 64, 435 .increment = 0 436 }, 437 .digest_size = { 438 .min = 12, 439 .max = 12, 440 .increment = 0 441 }, 442 .aad_size = { 0 }, 443 .iv_size = { 0 } 444 } 445 } 446 }, 447 { /* AES CBC */ 448 .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC, 449 .sym = { 450 .xform_type = RTE_CRYPTO_SYM_XFORM_CIPHER, 451 .cipher = { 452 .algo = RTE_CRYPTO_CIPHER_AES_CBC, 453 .block_size = 16, 454 .key_size = { 455 .min = 16, 456 .max = 32, 457 .increment = 8 458 }, 459 .iv_size = { 460 .min = 16, 461 .max = 16, 462 .increment = 0 463 } 464 } 465 } 466 } 467 } 468 469Below is an example of the capabilities for a PMD which supports the DOCSIS 470protocol. 471 472.. code-block:: c 473 474 static const struct rte_security_capability pmd_security_capabilities[] = { 475 { /* DOCSIS Uplink */ 476 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL, 477 .protocol = RTE_SECURITY_PROTOCOL_DOCSIS, 478 .docsis = { 479 .direction = RTE_SECURITY_DOCSIS_UPLINK 480 }, 481 .crypto_capabilities = pmd_capabilities 482 }, 483 { /* DOCSIS Downlink */ 484 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL, 485 .protocol = RTE_SECURITY_PROTOCOL_DOCSIS, 486 .docsis = { 487 .direction = RTE_SECURITY_DOCSIS_DOWNLINK 488 }, 489 .crypto_capabilities = pmd_capabilities 490 }, 491 { 492 .action = RTE_SECURITY_ACTION_TYPE_NONE 493 } 494 }; 495 static const struct rte_cryptodev_capabilities pmd_capabilities[] = { 496 { /* AES DOCSIS BPI */ 497 .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC, 498 .sym = { 499 .xform_type = RTE_CRYPTO_SYM_XFORM_CIPHER, 500 .cipher = { 501 .algo = RTE_CRYPTO_CIPHER_AES_DOCSISBPI, 502 .block_size = 16, 503 .key_size = { 504 .min = 16, 505 .max = 32, 506 .increment = 16 507 }, 508 .iv_size = { 509 .min = 16, 510 .max = 16, 511 .increment = 0 512 } 513 } 514 } 515 }, 516 517 RTE_CRYPTODEV_END_OF_CAPABILITIES_LIST() 518 }; 519 520Capabilities Discovery 521~~~~~~~~~~~~~~~~~~~~~~ 522 523Discovering the features and capabilities of a driver (crypto/ethernet) 524is achieved through the ``rte_security_capabilities_get()`` function. 525 526.. code-block:: c 527 528 const struct rte_security_capability *rte_security_capabilities_get(uint16_t id); 529 530This allows the user to query a specific driver and get all device 531security capabilities. It returns an array of ``rte_security_capability`` structures 532which contains all the capabilities for that device. 533 534Security Session Create/Free 535~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 536 537Security Sessions are created to store the immutable fields of a particular Security 538Association for a particular protocol which is defined by a security session 539configuration structure which is used in the operation processing of a packet flow. 540Sessions are used to manage protocol specific information as well as crypto parameters. 541Security sessions cache this immutable data in a optimal way for the underlying PMD 542and this allows further acceleration of the offload of Crypto workloads. 543 544The Security framework provides APIs to create and free sessions for crypto/ethernet 545devices, where sessions are mempool objects. It is the application's responsibility 546to create and manage two session mempools - one for session and other for session 547private data. The private session data mempool object size should be able to 548accommodate the driver's private data of security session. The application can get 549the size of session private data using API ``rte_security_session_get_size``. 550And the session mempool object size should be enough to accommodate 551``rte_security_session``. 552 553Once the session mempools have been created, ``rte_security_session_create()`` 554is used to allocate and initialize a session for the required crypto/ethernet device. 555 556Session APIs need a parameter ``rte_security_ctx`` to identify the crypto/ethernet 557security ops. This parameter can be retrieved using the APIs 558``rte_cryptodev_get_sec_ctx()`` (for crypto device) or ``rte_eth_dev_get_sec_ctx`` 559(for ethernet port). 560 561Sessions already created can be updated with ``rte_security_session_update()``. 562 563When a session is no longer used, the user must call ``rte_security_session_destroy()`` 564to free the driver private session data and return the memory back to the mempool. 565 566For look aside protocol offload to hardware crypto device, the ``rte_crypto_op`` 567created by the application is attached to the security session by the API 568``rte_security_attach_session()``. 569 570For Inline Crypto and Inline protocol offload, device specific defined metadata is 571updated in the mbuf using ``rte_security_set_pkt_metadata()`` if 572``RTE_ETH_TX_OFFLOAD_SEC_NEED_MDATA`` is set. 573 574For inline protocol offloaded ingress traffic, the application can register a 575pointer, ``userdata`` , in the security session. When the packet is received, 576``rte_security_get_userdata()`` would return the userdata registered for the 577security session which processed the packet. 578 579.. note:: 580 581 In case of inline processed packets, ``RTE_SECURITY_DYNFIELD_NAME`` field 582 would be used by the driver to relay information on the security processing 583 associated with the packet. In ingress, the driver would set this in Rx 584 path while in egress, ``rte_security_set_pkt_metadata()`` would perform a 585 similar operation. The application is expected not to modify the field 586 when it has relevant info. For ingress, this device-specific 64 bit value 587 is required to derive other information (like userdata), required for 588 identifying the security processing done on the packet. 589 590Security session configuration 591~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 592 593Security Session configuration structure is defined as ``rte_security_session_conf`` 594 595.. code-block:: c 596 597 struct rte_security_session_conf { 598 enum rte_security_session_action_type action_type; 599 /**< Type of action to be performed on the session */ 600 enum rte_security_session_protocol protocol; 601 /**< Security protocol to be configured */ 602 union { 603 struct rte_security_ipsec_xform ipsec; 604 struct rte_security_macsec_xform macsec; 605 struct rte_security_pdcp_xform pdcp; 606 struct rte_security_docsis_xform docsis; 607 }; 608 /**< Configuration parameters for security session */ 609 struct rte_crypto_sym_xform *crypto_xform; 610 /**< Security Session Crypto Transformations */ 611 void *userdata; 612 /**< Application specific userdata to be saved with session */ 613 }; 614 615The configuration structure reuses the ``rte_crypto_sym_xform`` struct for crypto related 616configuration. The ``rte_security_session_action_type`` struct is used to specify whether the 617session is configured for Lookaside Protocol offload or Inline Crypto or Inline Protocol 618Offload. 619 620.. code-block:: c 621 622 enum rte_security_session_action_type { 623 RTE_SECURITY_ACTION_TYPE_NONE, 624 /**< No security actions */ 625 RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO, 626 /**< Crypto processing for security protocol is processed inline 627 * during transmission 628 */ 629 RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL, 630 /**< All security protocol processing is performed inline during 631 * transmission 632 */ 633 RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL, 634 /**< All security protocol processing including crypto is performed 635 * on a lookaside accelerator 636 */ 637 RTE_SECURITY_ACTION_TYPE_CPU_CRYPTO 638 /**< Similar to ACTION_TYPE_NONE but crypto processing for security 639 * protocol is processed synchronously by a CPU. 640 */ 641 }; 642 643The ``rte_security_session_protocol`` is defined as 644 645.. code-block:: c 646 647 enum rte_security_session_protocol { 648 RTE_SECURITY_PROTOCOL_IPSEC = 1, 649 /**< IPsec Protocol */ 650 RTE_SECURITY_PROTOCOL_MACSEC, 651 /**< MACSec Protocol */ 652 RTE_SECURITY_PROTOCOL_PDCP, 653 /**< PDCP Protocol */ 654 RTE_SECURITY_PROTOCOL_DOCSIS, 655 /**< DOCSIS Protocol */ 656 }; 657 658Currently the library defines configuration parameters for IPsec and PDCP only. 659For other protocols like MACSec, structures and enums are defined as place holders 660which will be updated in the future. 661 662IPsec related configuration parameters are defined in ``rte_security_ipsec_xform`` 663 664PDCP related configuration parameters are defined in ``rte_security_pdcp_xform`` 665 666DOCSIS related configuration parameters are defined in ``rte_security_docsis_xform`` 667 668 669Security API 670~~~~~~~~~~~~ 671 672The rte_security Library API is described in the *DPDK API Reference* document. 673 674Flow based Security Session 675~~~~~~~~~~~~~~~~~~~~~~~~~~~ 676 677In the case of NIC based offloads, the security session specified in the 678'rte_flow_action_security' must be created on the same port as the 679flow action that is being specified. 680 681The ingress/egress flow attribute should match that specified in the security 682session if the security session supports the definition of the direction. 683 684Multiple flows can be configured to use the same security session. For 685example if the security session specifies an egress IPsec SA, then multiple 686flows can be specified to that SA. In the case of an ingress IPsec SA then 687it is only valid to have a single flow to map to that security session. 688 689.. code-block:: console 690 691 Configuration Path 692 | 693 +--------|--------+ 694 | Add/Remove | 695 | IPsec SA | <------ Build security flow action of 696 | | | ipsec transform 697 |--------|--------| 698 | 699 +--------V--------+ 700 | Flow API | 701 +--------|--------+ 702 | 703 +--------V--------+ 704 | | 705 | NIC PMD | <------ Add/Remove SA to/from hw context 706 | | 707 +--------|--------+ 708 | 709 +--------|--------+ 710 | HW ACCELERATED | 711 | NIC | 712 | | 713 +--------|--------+ 714 715* Add/Delete SA flow: 716 To add a new inline SA construct a rte_flow_item for Ethernet + IP + ESP 717 using the SA selectors and the ``rte_crypto_ipsec_xform`` as the ``rte_flow_action``. 718 Note that any rte_flow_items may be empty, which means it is not checked. 719 720.. code-block:: console 721 722 In its most basic form, IPsec flow specification is as follows: 723 +-------+ +----------+ +--------+ +-----+ 724 | Eth | -> | IP4/6 | -> | ESP | -> | END | 725 +-------+ +----------+ +--------+ +-----+ 726 727 However, the API can represent, IPsec crypto offload with any encapsulation: 728 +-------+ +--------+ +-----+ 729 | Eth | -> ... -> | ESP | -> | END | 730 +-------+ +--------+ +-----+ 731 732 733Telemetry support 734----------------- 735 736The Security library has support for displaying Crypto device information 737with respect to its Security capabilities. Telemetry commands that can be used 738are shown below. 739 740#. Get the list of available Crypto devices by ID, that supports Security features:: 741 742 --> /security/cryptodev/list 743 {"/security/cryptodev/list": [0, 1, 2, 3]} 744 745#. Get the security capabilities of a Crypto device:: 746 747 --> /security/cryptodev/sec_caps,0 748 {"/security/cryptodev/sec_caps": {"sec_caps": [<array of serialized bytes of 749 capabilities>], "sec_caps_n": <number of capabilities>}} 750 751 #. Get the security crypto capabilities of a Crypto device:: 752 753 --> /security/cryptodev/crypto_caps,0,0 754 {"/security/cryptodev/crypto_caps": {"crypto_caps": [<array of serialized bytes of 755 capabilities>], "crypto_caps_n": <number of capabilities>}} 756 757For more information on how to use the Telemetry interface, see 758the :doc:`../howto/telemetry`. 759