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, 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_mbuf.udata64`` field. This will allow the application 129to identify the security processing done on the packet. 130 131.. note:: 132 133 The underlying device in this case is stateful. It is expected that 134 the device shall support crypto processing for all kind of packets matching 135 to a given flow, this includes fragmented packets (post reassembly). 136 E.g. in case of IPsec the device may internally manage anti-replay etc. 137 It will provide a configuration option for anti-replay behavior i.e. to drop 138 the packets or pass them to driver with error flags set in the descriptor. 139 140Egress Data path - The software will send the plain packet without any 141security protocol headers added to the packet. The driver will configure 142the security index and other requirement in tx descriptors. 143The hardware device will do security processing on the packet that includes 144adding the relevant protocol headers and encrypting the data before sending 145the packet out. The software should make sure that the buffer 146has required head room and tail room for any protocol header addition. The 147software may also do early fragmentation if the resultant packet is expected 148to cross the MTU size. 149 150 151.. note:: 152 153 The underlying device will manage state information required for egress 154 processing. E.g. in case of IPsec, the seq number will be added to the 155 packet, however the device shall provide indication when the sequence number 156 is about to overflow. The underlying device may support post encryption TSO. 157 158.. code-block:: console 159 160 Egress Data Path 161 | 162 +--------|--------+ 163 | egress IPsec | 164 | | | 165 | +------V------+ | 166 | | SADB lookup | | 167 | +------|------+ | 168 | +------V------+ | 169 | | Desc | | <------ Mark packet to be offloaded 170 | +------|------+ | 171 +--------V--------+ 172 | 173 +--------V--------+ 174 | L2 Stack | 175 +--------|--------+ 176 | 177 +--------V--------+ 178 | | 179 | NIC PMD | <------ Set hw context for inline crypto offload 180 | | 181 +--------|--------+ 182 | 183 +--------|--------+ 184 | HW ACCELERATED | <------ Add tunnel, ESP header etc header to 185 | NIC | packet. Packet Encryption and 186 | | Authentication happens inline. 187 +-----------------+ 188 189 190Lookaside protocol offload 191~~~~~~~~~~~~~~~~~~~~~~~~~~ 192 193RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL: 194This extends librte_cryptodev to support the programming of IPsec 195Security Association (SA) as part of a crypto session creation including 196the definition. In addition to standard crypto processing, as defined by 197the cryptodev, the security protocol processing is also offloaded to the 198crypto device. 199 200Decryption: The packet is sent to the crypto device for security 201protocol processing. The device will decrypt the packet and it will also 202optionally remove additional security headers from the packet. 203E.g. in case of IPsec, IPsec tunnel headers (if any), ESP/AH headers 204will be removed from the packet and the decrypted packet may contain 205plain data only. 206 207.. note:: 208 209 In case of IPsec the device may internally manage anti-replay etc. 210 It will provide a configuration option for anti-replay behavior i.e. to drop 211 the packets or pass them to driver with error flags set in descriptor. 212 213Encryption: The software will submit the packet to cryptodev as usual 214for encryption, the hardware device in this case will also add the relevant 215security protocol header along with encrypting the packet. The software 216should make sure that the buffer has required head room and tail room 217for any protocol header addition. 218 219.. note:: 220 221 In the case of IPsec, the seq number will be added to the packet, 222 It shall provide an indication when the sequence number is about to 223 overflow. 224 225.. code-block:: console 226 227 Egress Data Path 228 | 229 +--------|--------+ 230 | egress IPsec | 231 | | | 232 | +------V------+ | 233 | | SADB lookup | | <------ SA maps to cryptodev session 234 | +------|------+ | 235 | +------|------+ | 236 | | \--------------------\ 237 | | Crypto | | | <- Crypto processing through 238 | | /----------------\ | inline crypto PMD 239 | +------|------+ | | | 240 +--------V--------+ | | 241 | | | 242 +--------V--------+ | | create <-- SA is added to hw 243 | L2 Stack | | | inline using existing create 244 +--------|--------+ | | session sym session APIs 245 | | | | 246 +--------V--------+ +---|---|----V---+ 247 | | | \---/ | | <--- Add tunnel, ESP header etc 248 | NIC PMD | | INLINE | | header to packet.Packet 249 | | | CRYPTO PMD | | Encryption/Decryption and 250 +--------|--------+ +----------------+ Authentication happens 251 | inline. 252 +--------|--------+ 253 | NIC | 254 +--------|--------+ 255 V 256 257PDCP Flow Diagram 258~~~~~~~~~~~~~~~~~ 259 260Based on 3GPP TS 36.323 Evolved Universal Terrestrial Radio Access (E-UTRA); 261Packet Data Convergence Protocol (PDCP) specification 262 263.. code-block:: c 264 265 Transmitting PDCP Entity Receiving PDCP Entity 266 | ^ 267 | +-----------|-----------+ 268 V | In order delivery and | 269 +---------|----------+ | Duplicate detection | 270 | Sequence Numbering | | (Data Plane only) | 271 +---------|----------+ +-----------|-----------+ 272 | | 273 +---------|----------+ +-----------|----------+ 274 | Header Compression*| | Header Decompression*| 275 | (Data-Plane only) | | (Data Plane only) | 276 +---------|----------+ +-----------|----------+ 277 | | 278 +---------|-----------+ +-----------|----------+ 279 | Integrity Protection| |Integrity Verification| 280 | (Control Plane only)| | (Control Plane only) | 281 +---------|-----------+ +-----------|----------+ 282 +---------|-----------+ +----------|----------+ 283 | Ciphering | | Deciphering | 284 +---------|-----------+ +----------|----------+ 285 +---------|-----------+ +----------|----------+ 286 | Add PDCP header | | Remove PDCP Header | 287 +---------|-----------+ +----------|----------+ 288 | | 289 +----------------->>----------------+ 290 291 292.. note:: 293 294 * Header Compression and decompression are not supported currently. 295 296Just like IPsec, in case of PDCP also header addition/deletion, cipher/ 297de-cipher, integrity protection/verification is done based on the action 298type chosen. 299 300DOCSIS Protocol 301~~~~~~~~~~~~~~~ 302 303The Data Over Cable Service Interface Specification (DOCSIS) support comprises 304the combination of encryption/decryption and CRC generation/verification, for 305use in a DOCSIS-MAC pipeline. 306 307.. code-block:: c 308 309 310 Downlink Uplink 311 -------- ------ 312 313 Ethernet frame Ethernet frame 314 from core network to core network 315 | ^ 316 ~ | 317 | ~ ----+ 318 V | | 319 +---------|----------+ +----------|---------+ | 320 | CRC generation | | CRC verification | | 321 +---------|----------+ +----------|---------+ | combined 322 | | > Crypto + CRC 323 +---------|----------+ +----------|---------+ | 324 | Encryption | | Decryption | | 325 +---------|----------+ +----------|---------+ | 326 | ^ | 327 ~ | ----+ 328 | ~ 329 V | 330 DOCSIS frame DOCSIS frame 331 to Cable Modem from Cable Modem 332 333The encryption/decryption is a combination of CBC and CFB modes using either AES 334or DES algorithms as specified in the DOCSIS Security Specification (from DPDK 335lib_rtecryptodev perspective, these are RTE_CRYPTO_CIPHER_AES_DOCSISBPI and 336RTE_CRYPTO_CIPHER_DES_DOCSISBPI). 337 338The CRC is Ethernet CRC-32 as specified in Ethernet/[ISO/IEC 8802-3]. 339 340.. note:: 341 342 * The offset and length of data for which CRC needs to be computed are 343 specified via the auth offset and length fields of the rte_crypto_sym_op. 344 * Other DOCSIS protocol functionality such as Header Checksum (HCS) 345 calculation may be added in the future. 346 347Device Features and Capabilities 348--------------------------------- 349 350Device Capabilities For Security Operations 351~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 352 353The device (crypto or ethernet) capabilities which support security operations, 354are defined by the security action type, security protocol, protocol 355capabilities and corresponding crypto capabilities for security. For the full 356scope of the Security capability see definition of rte_security_capability 357structure in the *DPDK API Reference*. 358 359.. code-block:: c 360 361 struct rte_security_capability; 362 363Each driver (crypto or ethernet) defines its own private array of capabilities 364for the operations it supports. Below is an example of the capabilities for a 365PMD which supports the IPsec and PDCP protocol. 366 367.. code-block:: c 368 369 static const struct rte_security_capability pmd_security_capabilities[] = { 370 { /* IPsec Lookaside Protocol offload ESP Tunnel Egress */ 371 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL, 372 .protocol = RTE_SECURITY_PROTOCOL_IPSEC, 373 .ipsec = { 374 .proto = RTE_SECURITY_IPSEC_SA_PROTO_ESP, 375 .mode = RTE_SECURITY_IPSEC_SA_MODE_TUNNEL, 376 .direction = RTE_SECURITY_IPSEC_SA_DIR_EGRESS, 377 .options = { 0 } 378 }, 379 .crypto_capabilities = pmd_capabilities 380 }, 381 { /* IPsec Lookaside Protocol offload ESP Tunnel Ingress */ 382 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL, 383 .protocol = RTE_SECURITY_PROTOCOL_IPSEC, 384 .ipsec = { 385 .proto = RTE_SECURITY_IPSEC_SA_PROTO_ESP, 386 .mode = RTE_SECURITY_IPSEC_SA_MODE_TUNNEL, 387 .direction = RTE_SECURITY_IPSEC_SA_DIR_INGRESS, 388 .options = { 0 } 389 }, 390 .crypto_capabilities = pmd_capabilities 391 }, 392 { /* PDCP Lookaside Protocol offload Data Plane */ 393 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL, 394 .protocol = RTE_SECURITY_PROTOCOL_PDCP, 395 .pdcp = { 396 .domain = RTE_SECURITY_PDCP_MODE_DATA, 397 .capa_flags = 0 398 }, 399 .crypto_capabilities = pmd_capabilities 400 }, 401 { /* PDCP Lookaside Protocol offload Control */ 402 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL, 403 .protocol = RTE_SECURITY_PROTOCOL_PDCP, 404 .pdcp = { 405 .domain = RTE_SECURITY_PDCP_MODE_CONTROL, 406 .capa_flags = 0 407 }, 408 .crypto_capabilities = pmd_capabilities 409 }, 410 { 411 .action = RTE_SECURITY_ACTION_TYPE_NONE 412 } 413 }; 414 static const struct rte_cryptodev_capabilities pmd_capabilities[] = { 415 { /* SHA1 HMAC */ 416 .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC, 417 .sym = { 418 .xform_type = RTE_CRYPTO_SYM_XFORM_AUTH, 419 .auth = { 420 .algo = RTE_CRYPTO_AUTH_SHA1_HMAC, 421 .block_size = 64, 422 .key_size = { 423 .min = 64, 424 .max = 64, 425 .increment = 0 426 }, 427 .digest_size = { 428 .min = 12, 429 .max = 12, 430 .increment = 0 431 }, 432 .aad_size = { 0 }, 433 .iv_size = { 0 } 434 } 435 } 436 }, 437 { /* AES CBC */ 438 .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC, 439 .sym = { 440 .xform_type = RTE_CRYPTO_SYM_XFORM_CIPHER, 441 .cipher = { 442 .algo = RTE_CRYPTO_CIPHER_AES_CBC, 443 .block_size = 16, 444 .key_size = { 445 .min = 16, 446 .max = 32, 447 .increment = 8 448 }, 449 .iv_size = { 450 .min = 16, 451 .max = 16, 452 .increment = 0 453 } 454 } 455 } 456 } 457 } 458 459Below is an example of the capabilities for a PMD which supports the DOCSIS 460protocol. 461 462.. code-block:: c 463 464 static const struct rte_security_capability pmd_security_capabilities[] = { 465 { /* DOCSIS Uplink */ 466 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL, 467 .protocol = RTE_SECURITY_PROTOCOL_DOCSIS, 468 .docsis = { 469 .direction = RTE_SECURITY_DOCSIS_UPLINK 470 }, 471 .crypto_capabilities = pmd_capabilities 472 }, 473 { /* DOCSIS Downlink */ 474 .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL, 475 .protocol = RTE_SECURITY_PROTOCOL_DOCSIS, 476 .docsis = { 477 .direction = RTE_SECURITY_DOCSIS_DOWNLINK 478 }, 479 .crypto_capabilities = pmd_capabilities 480 }, 481 { 482 .action = RTE_SECURITY_ACTION_TYPE_NONE 483 } 484 }; 485 static const struct rte_cryptodev_capabilities pmd_capabilities[] = { 486 { /* AES DOCSIS BPI */ 487 .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC, 488 .sym = { 489 .xform_type = RTE_CRYPTO_SYM_XFORM_CIPHER, 490 .cipher = { 491 .algo = RTE_CRYPTO_CIPHER_AES_DOCSISBPI, 492 .block_size = 16, 493 .key_size = { 494 .min = 16, 495 .max = 32, 496 .increment = 16 497 }, 498 .iv_size = { 499 .min = 16, 500 .max = 16, 501 .increment = 0 502 } 503 } 504 } 505 }, 506 507 RTE_CRYPTODEV_END_OF_CAPABILITIES_LIST() 508 }; 509 510Capabilities Discovery 511~~~~~~~~~~~~~~~~~~~~~~ 512 513Discovering the features and capabilities of a driver (crypto/ethernet) 514is achieved through the ``rte_security_capabilities_get()`` function. 515 516.. code-block:: c 517 518 const struct rte_security_capability *rte_security_capabilities_get(uint16_t id); 519 520This allows the user to query a specific driver and get all device 521security capabilities. It returns an array of ``rte_security_capability`` structures 522which contains all the capabilities for that device. 523 524Security Session Create/Free 525~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 526 527Security Sessions are created to store the immutable fields of a particular Security 528Association for a particular protocol which is defined by a security session 529configuration structure which is used in the operation processing of a packet flow. 530Sessions are used to manage protocol specific information as well as crypto parameters. 531Security sessions cache this immutable data in a optimal way for the underlying PMD 532and this allows further acceleration of the offload of Crypto workloads. 533 534The Security framework provides APIs to create and free sessions for crypto/ethernet 535devices, where sessions are mempool objects. It is the application's responsibility 536to create and manage the session mempools. The mempool object size should be able to 537accommodate the driver's private data of security session. 538 539Once the session mempools have been created, ``rte_security_session_create()`` 540is used to allocate and initialize a session for the required crypto/ethernet device. 541 542Session APIs need a parameter ``rte_security_ctx`` to identify the crypto/ethernet 543security ops. This parameter can be retrieved using the APIs 544``rte_cryptodev_get_sec_ctx()`` (for crypto device) or ``rte_eth_dev_get_sec_ctx`` 545(for ethernet port). 546 547Sessions already created can be updated with ``rte_security_session_update()``. 548 549When a session is no longer used, the user must call ``rte_security_session_destroy()`` 550to free the driver private session data and return the memory back to the mempool. 551 552For look aside protocol offload to hardware crypto device, the ``rte_crypto_op`` 553created by the application is attached to the security session by the API 554``rte_security_attach_session()``. 555 556For Inline Crypto and Inline protocol offload, device specific defined metadata is 557updated in the mbuf using ``rte_security_set_pkt_metadata()`` if 558``DEV_TX_OFFLOAD_SEC_NEED_MDATA`` is set. 559 560For inline protocol offloaded ingress traffic, the application can register a 561pointer, ``userdata`` , in the security session. When the packet is received, 562``rte_security_get_userdata()`` would return the userdata registered for the 563security session which processed the packet. 564 565.. note:: 566 567 In case of inline processed packets, ``rte_mbuf.udata64`` field would be 568 used by the driver to relay information on the security processing 569 associated with the packet. In ingress, the driver would set this in Rx 570 path while in egress, ``rte_security_set_pkt_metadata()`` would perform a 571 similar operation. The application is expected not to modify the field 572 when it has relevant info. For ingress, this device-specific 64 bit value 573 is required to derive other information (like userdata), required for 574 identifying the security processing done on the packet. 575 576Security session configuration 577~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 578 579Security Session configuration structure is defined as ``rte_security_session_conf`` 580 581.. code-block:: c 582 583 struct rte_security_session_conf { 584 enum rte_security_session_action_type action_type; 585 /**< Type of action to be performed on the session */ 586 enum rte_security_session_protocol protocol; 587 /**< Security protocol to be configured */ 588 union { 589 struct rte_security_ipsec_xform ipsec; 590 struct rte_security_macsec_xform macsec; 591 struct rte_security_pdcp_xform pdcp; 592 struct rte_security_docsis_xform docsis; 593 }; 594 /**< Configuration parameters for security session */ 595 struct rte_crypto_sym_xform *crypto_xform; 596 /**< Security Session Crypto Transformations */ 597 void *userdata; 598 /**< Application specific userdata to be saved with session */ 599 }; 600 601The configuration structure reuses the ``rte_crypto_sym_xform`` struct for crypto related 602configuration. The ``rte_security_session_action_type`` struct is used to specify whether the 603session is configured for Lookaside Protocol offload or Inline Crypto or Inline Protocol 604Offload. 605 606.. code-block:: c 607 608 enum rte_security_session_action_type { 609 RTE_SECURITY_ACTION_TYPE_NONE, 610 /**< No security actions */ 611 RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO, 612 /**< Crypto processing for security protocol is processed inline 613 * during transmission 614 */ 615 RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL, 616 /**< All security protocol processing is performed inline during 617 * transmission 618 */ 619 RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL, 620 /**< All security protocol processing including crypto is performed 621 * on a lookaside accelerator 622 */ 623 RTE_SECURITY_ACTION_TYPE_CPU_CRYPTO 624 /**< Similar to ACTION_TYPE_NONE but crypto processing for security 625 * protocol is processed synchronously by a CPU. 626 */ 627 }; 628 629The ``rte_security_session_protocol`` is defined as 630 631.. code-block:: c 632 633 enum rte_security_session_protocol { 634 RTE_SECURITY_PROTOCOL_IPSEC = 1, 635 /**< IPsec Protocol */ 636 RTE_SECURITY_PROTOCOL_MACSEC, 637 /**< MACSec Protocol */ 638 RTE_SECURITY_PROTOCOL_PDCP, 639 /**< PDCP Protocol */ 640 RTE_SECURITY_PROTOCOL_DOCSIS, 641 /**< DOCSIS Protocol */ 642 }; 643 644Currently the library defines configuration parameters for IPsec and PDCP only. 645For other protocols like MACSec, structures and enums are defined as place holders 646which will be updated in the future. 647 648IPsec related configuration parameters are defined in ``rte_security_ipsec_xform`` 649 650.. code-block:: c 651 652 struct rte_security_ipsec_xform { 653 uint32_t spi; 654 /**< SA security parameter index */ 655 uint32_t salt; 656 /**< SA salt */ 657 struct rte_security_ipsec_sa_options options; 658 /**< various SA options */ 659 enum rte_security_ipsec_sa_direction direction; 660 /**< IPsec SA Direction - Egress/Ingress */ 661 enum rte_security_ipsec_sa_protocol proto; 662 /**< IPsec SA Protocol - AH/ESP */ 663 enum rte_security_ipsec_sa_mode mode; 664 /**< IPsec SA Mode - transport/tunnel */ 665 struct rte_security_ipsec_tunnel_param tunnel; 666 /**< Tunnel parameters, NULL for transport mode */ 667 }; 668 669PDCP related configuration parameters are defined in ``rte_security_pdcp_xform`` 670 671.. code-block:: c 672 673 struct rte_security_pdcp_xform { 674 int8_t bearer; /**< PDCP bearer ID */ 675 /** Enable in order delivery, this field shall be set only if 676 * driver/HW is capable. See RTE_SECURITY_PDCP_ORDERING_CAP. 677 */ 678 uint8_t en_ordering; 679 /** Notify driver/HW to detect and remove duplicate packets. 680 * This field should be set only when driver/hw is capable. 681 * See RTE_SECURITY_PDCP_DUP_DETECT_CAP. 682 */ 683 uint8_t remove_duplicates; 684 /** PDCP mode of operation: Control or data */ 685 enum rte_security_pdcp_domain domain; 686 /** PDCP Frame Direction 0:UL 1:DL */ 687 enum rte_security_pdcp_direction pkt_dir; 688 /** Sequence number size, 5/7/12/15/18 */ 689 enum rte_security_pdcp_sn_size sn_size; 690 /** Starting Hyper Frame Number to be used together with the SN 691 * from the PDCP frames 692 */ 693 uint32_t hfn; 694 /** HFN Threshold for key renegotiation */ 695 uint32_t hfn_threshold; 696 }; 697 698DOCSIS related configuration parameters are defined in ``rte_security_docsis_xform`` 699 700.. code-block:: c 701 702 struct rte_security_docsis_xform { 703 enum rte_security_docsis_direction direction; 704 /**< DOCSIS direction */ 705 }; 706 707 708Security API 709~~~~~~~~~~~~ 710 711The rte_security Library API is described in the *DPDK API Reference* document. 712 713Flow based Security Session 714~~~~~~~~~~~~~~~~~~~~~~~~~~~ 715 716In the case of NIC based offloads, the security session specified in the 717'rte_flow_action_security' must be created on the same port as the 718flow action that is being specified. 719 720The ingress/egress flow attribute should match that specified in the security 721session if the security session supports the definition of the direction. 722 723Multiple flows can be configured to use the same security session. For 724example if the security session specifies an egress IPsec SA, then multiple 725flows can be specified to that SA. In the case of an ingress IPsec SA then 726it is only valid to have a single flow to map to that security session. 727 728.. code-block:: console 729 730 Configuration Path 731 | 732 +--------|--------+ 733 | Add/Remove | 734 | IPsec SA | <------ Build security flow action of 735 | | | ipsec transform 736 |--------|--------| 737 | 738 +--------V--------+ 739 | Flow API | 740 +--------|--------+ 741 | 742 +--------V--------+ 743 | | 744 | NIC PMD | <------ Add/Remove SA to/from hw context 745 | | 746 +--------|--------+ 747 | 748 +--------|--------+ 749 | HW ACCELERATED | 750 | NIC | 751 | | 752 +--------|--------+ 753 754* Add/Delete SA flow: 755 To add a new inline SA construct a rte_flow_item for Ethernet + IP + ESP 756 using the SA selectors and the ``rte_crypto_ipsec_xform`` as the ``rte_flow_action``. 757 Note that any rte_flow_items may be empty, which means it is not checked. 758 759.. code-block:: console 760 761 In its most basic form, IPsec flow specification is as follows: 762 +-------+ +----------+ +--------+ +-----+ 763 | Eth | -> | IP4/6 | -> | ESP | -> | END | 764 +-------+ +----------+ +--------+ +-----+ 765 766 However, the API can represent, IPsec crypto offload with any encapsulation: 767 +-------+ +--------+ +-----+ 768 | Eth | -> ... -> | ESP | -> | END | 769 +-------+ +--------+ +-----+ 770