New Crypto Offload Framework in DPDK - Security Acceleration Overview
This content delves into a new crypto offload framework within DPDK, emphasizing security acceleration through various protocols and hardware acceleration modes like Lookaside and Inline Crypto. The comprehensive agenda covers introduction, encryption packet processing, and lookaside protocol acceleration details, providing insights into managing security sessions and hardware provisioning. Discover how this framework enhances security operations and supports a range of protocols and applications.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
rte_security: A new crypto-offload framework in DPDK Hemant Agrawal (NXP) Akhil Goyal (NXP) DPDK Summit - India- 2018
Agenda Introduction Acceleration enablement modes Lookaside Security Protocol Inline Crypto Inline Security Protocol Security Library Details Summary & Future Work Q&A
Introduction rte_security Framework for management and provisioning of hardware acceleration of security protocols. Generic APIs to manage security sessions. Security Library Net/Crypto device PMD initializes a security context which is used to access security operations on that particular device. Net PMD Crypto PMD Rich capabilities discovery APIs Currently IP Security (IPsec) protocol is supported. Could support a wide variety of protocols/applications Enterprise/SMB VPNs IPsec Wireless backhaul IPsec, PDCP Data-center SSL WLAN backhaul CAPWAP/DTLS Control-plane options for above PKCS, RNG
IPSEC - Encrypt Packet Processing L2 process and transmission Flow and SPD/SA Lookup Pre-Protocol Processing Post-Protocol Processing Crypto Processing Packet Received IP Header Addition Encryption Authentication Sequence Number Random IV generation Block Cipher Padding Tunnel Header Preparations (TOS/ECN/DF etc)
Lookaside Protocol, Hardware Acceleration Modes Inline Crypto, Inline Protocol
Lookaside Protocol Acceleration Packet is given to an accelerator for processing and then returned to the host after processing is complete. Application provides session information to configure a security IPsec SA on the accelerator. Crypto_op uses security session to enqueue/dequeue packets to/from crypto PMD. Support full protocol (IPsec) processing on the accelerator. Including: Add/remove protocol headers, including IP tunnel headers as well as IPsec (AH/ESP) headers. Handling SA state information: Sequence number overflow Anti-replay window
Lookaside Protocol Processing Example - IPsec ESP Tunnel Encrypt Input Frame: Payload Lookaside Protocol Accelerator adds Crypto: Class 1 ESP header Pad Len Payload padding N Initialization Vector (IV) Encrypted Pad Len Payload padding N ESP trailer Class 2 Integrity check value (ICV) Opt IV Pad Len Outer IP header/NAT-T header Payload padding N SPI Seq# Opt ESN Authenticate Calculates IP header length Output Frame: Calculate header checksum. Opt IV Pad Len New IP Header Payload padding N SPI Seq# ICV Esp header
Inline Crypto Acceleration IO based acceleration performed on the physical interface as packet ingress/egress. No packet headers modifications* on the hardware, only encryption/decryption and authentication operations are performed. Requires that Ethernet CRC is also offloaded to the physical interface. *Hardware may support extra features like payload padding etc.
Inline Crypto Ingress Data Path HW performs the following for matching (SIP, DIP, ESP)* packets: Decryption and authentication processing mark the result in metadata Remove the ESP trailer* PMD provides the following info per packet: Crypto result success/failure. Inner ESP next protocol* Packet without a trailer* Application: Check mbuf->ol_flags for PKT_RX_SEC_OFFLOAD / PKT_RX_SEC_OFFLOAD_FAILED Read the inner ESP next protocol to remove the ESP header * Support is hardware dependent, there may be some variation.
Inline Crypto Ingress Data Path MBUF IP ESP IP PAYLOAD PAD ESP AUTH MBUF IP ESP IP PAYLOAD PAD ESP AUTH LOOK- ASIDE CRYPTO IP ESP ENCRYPTED PAYLOAD AUTH NICHW IPSEC PRE- CRYPTO IPSEC POST- CRYPTO SP/SA LOOKUP HOST CRYPTO PIPELINE STAGES PMD L2/3 L3 INGRESS CLASSIFY [ ol_flags == processed inline ] [ success ] INLINE CRYPTO INLINE STATUS IP ESP IP PAYLOAD PAD ESP AUTH MBUF IP ESP IP PAYLOAD PAD ESP AUTH
Inline Crypto Egress Data Path Application: Mark mbuf->ol_flags using PKT_TX_SEC_OFFLOAD Marks packet with IPsec as ESP tunnel Set all security metadata in mbuf as needed, including inner_esp_next_proto according to inner packet* PMD can perform special processing on packets with the PKT_TX_SEC_OFFLOAD flag set, including: Inner ESP next protocol* Security Association Index for hardware* Processing for LSO support* HW performs the following for marked packets: Add the ESP trailer if supported Encryption and authentication *Exact requirements, if any, are hardware dependent
Inline Crypto Egress Data Path MBUF IP ESP IP PAYLOAD PAD ESP AUTH MBUF IP ESP IP PAYLOAD PAD ESP AUTH MBUF IP ESP IP PAYLOAD PAD ESP AUTH SET INLINE METADATA HW [ inline crypto == Yes ] IPSEC PRE- CRYPTO IPSEC POST- CRYPTO INLINE CRYPTO FILTER OTHER PIPELINE STAGES SP/SA LOOKUP HOST CRYPTO L3 L3/L2 PMD EGRESS IPSec LOOK- ASIDE CRYPTO INLINE CRYPTO MBUF IP PAYLOAD IP ESP ENCRYPTED PAYLOAD AUTH
Inline Protocol Acceleration IO based acceleration performed on the physical interface as the packet ingresses/egresses the platform. Interface performs all crypto processing for the security protocol (e.g. IPsec) during transmission and reception. Packet headers modification is performed on hardware including all state management and encryption/decryption and authentication operations. Hardware may support extra features like padding of payload etc. Application can retrieve the SA information stored in the userdata on the ingress side to identify the SA for which the packet is decrypted. Requires that ARP entries for MAC headers are programmed along with the security action, as host may not know destination IP in case of a tunnel mode SA
Library Implementation Core features of the librte_security
Library Features Protocol agnostic session API to manage protocol state on underlying hardware. Definitions of supported protocols, currently only IPsec, and the parameters for configuring the options. For IPsec this includes: Acceleration type inline crypto/lookaside protocol/inline protocol Defining security association (SA) parameters such as Tunnel/Transport, ESP/AH. Crypto configuration is reused from cryptodev i.e. crypto xforms. Capabilities APIs to allow dynamic discovery of supported features of PMD.
A multi-device API (Object Model) <<Interface>> rte_security <<Interface>> rte_ethdev <<Interface>> rte_cryptodev APIs APIs APIs rte_security_context rte_security_context - device - ops - device - ops rte_ethdev rte_cryptodev rte_device rte_device - device - ops - device - ops cryptodev_ops eth_dev_ops security_ops security_ops
Protocols and actions Select the session Protocol: rte_security_session_protocol IPSEC, MACSEC, SSL, PDCP etc. Select the Security Action Type: rte_security_session_action_type RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO: Inline crypto processing as NIC offload during recv/transmit. RTE_SECURITY_ACTION_TYPE_INLINE_PROTOCOL: Inline security protocol processing as NIC offload during recv/transmit. RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL: Security protocol processing including crypto on a crypto accelerator. Action type can be an input for the given application during SA creation Based on the action type and other SA related information, application configures session parameters for security offload.
Security APIs Get device context void *rte_cryptodev_get_sec_ctx(uint8_t dev_id) /* Security context for crypto/eth devices */ struct rte_security_ctx { void *device; /**< Crypto/ethernet device attached */ const struct rte_security_ops *ops; /**< Pointer to security ops for the device */ uint16_t sess_cnt; /**< Number of sessions attached to this context */ }; /** security session configuration parameters */ struct rte_security_session_conf config = { .action_type = RTE_SECURITY_ACTION_TYPE_INLINE_CRYPTO, /**< Type of action to be performed on the session */ .protocol = RTE_SECURITY_PROTOCOL_IPSEC, /**< Security protocol to be configured */ .ipsec = { .spi = /**< Security Protocol Index */, .salt = /** Salt value */, .direction = RTE_SECURITY_IPSEC_SA_DIR_INGRESS, .proto = RTE_SECURITY_IPSEC_SA_PROTO_ESP, .mode = RTE_SECURITY_IPSEC_SA_MODE_TUNNEL }, /**< Configuration parameters for security session */ .crypto_xform = /** crypto transforms */ /**< Security Session Crypto Transformations */ .userdata = /** Application specific User data */ }; void *rte_eth_dev_get_sec_ctx(uint8_t port_id) Create Session struct rte_security_session * rte_security_session_create( struct rte_security_ctx *instance, struct rte_security_session_conf *conf, struct rte_mempool *mp); Update (rte_security_session_update) Destroy (rte_security_session_destroy) Get Stats (rte_security_session_stats_get) Get userdata (rte_security_get_userdata) Set pkt metadata (rte_security_set_pkt_metadata) Attach session with crypto_op (rte_security_attach_session)
Security APIs contd. struct rte_security_ipsec_xform { uint32_t spi; uint32_t salt; struct rte_security_ipsec_sa_options options; enum rte_security_ipsec_sa_direction dir; /**< SA Direction Egress/Ingress */ enum rte_security_ipsec_sa_protocol proto; /**< SA Protocol AH/ESP */ enum rte_security_ipsec_sa_mode mode; /**< SA Mode Transport/Tunnel */ struct rte_security_ipsec_tunnel_param tunnel; /**< * SA Tunnel Parameter. Only applicable when SA is tunnel mode * and offload type is either inline/lookaside protocol */ }; IPsec SA options include: /**< SA security parameter index */ /**< Salt */ Extended Sequence Number Support NAT/UDP encapsulation, NAT-T L4 Checksum verify/update Qos/TOS copy support (inner to outer - tunnel) DF copy support (inner to outer - tunnel) TTL decrement support Address copy support (inner to outer for tunnel) Trailer add support Many parameters are applicable for Full Protocol Offload only Once the session is initialized, application can attach the session with crypto_op or set pkt metadata depending on action_type.
Capabilities Example struct rte_security_capability { enum rte_security_session_action_type action; /**< Security action type*/ enum rte_security_session_protocol protocol; /**< Security protocol */ union { struct { enum rte_security_ipsec_sa_protocol proto; /**< IPsec SA protocol */ enum rte_security_ipsec_sa_mode mode; /**< IPsec SA mode */ enum rte_security_ipsec_sa_direction direction; /**< IPsec SA direction */ struct rte_security_ipsec_sa_options options; /**< IPsec SA supported options */ } ipsec; /**< IPsec capability */ }; const struct rte_cryptodev_capabilities *crypto_capabilities; /**< Corresponding crypto capabilities for security capability */ uint32_t ol_flags; /**< Device offload flags */ }; { /* IPsec Lookaside Protocol offload ESP Tunnel Ingress */ .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL, .protocol = RTE_SECURITY_PROTOCOL_IPSEC, .ipsec = { .proto = RTE_SECURITY_IPSEC_SA_PROTO_ESP, .mode = RTE_SECURITY_IPSEC_SA_MODE_TUNNEL, .direction = RTE_SECURITY_IPSEC_SA_DIR_INGRESS, .options = { 0 } }, .crypto_capabilities = crypto_pmd_capabilities }, Capabilities API allow user to get all the capabilities of the devices or to query a single capability List of Capabilities const struct rte_security_capability * rte_security_capabilities_get( struct rte_security_ctx *instance); Check on Specific Capability const struct rte_security_capability * rte_security_capability_get( struct rte_security_ctx *instance, struct rte_security_capability_idx *idx);
Control Path Security Instance NET/CRYPTO PMD user HW set parameters in security_session_conf rte_security_session_create() nstance->ops->session_create() allocate SA entry program SA to hw sec_sess alt [inline crypto/inline protocol] rte_flow(flow,action=sec(sec_sess) dev->flow_ops->flow_create program classification table
Summary Provides an abstraction for provisioning security hw accelerations, initially targeting IPsec. Can be used with ethdev or cryptodev Agnostic API to allow applications to use different security accelerations. Since DPDK 17.11, IPsec Security Gateway Sample application is using rte_security to support inline crypto (on Intel s IXGBE NET PMD) and lookaside protocol acceleration (on NXP s DPAA/DPAA2 CRYPTO PMD). Go try it out!
Future Work Multi process support Enable Event based security sessions IPsec inline protocol offload Further protocol enablement MACsec, PDCP, DTLS, etc would fit under this model. Software equivalent enablement It could be possible to offer software equivalent processing under this API, may or may not be desirable depending on protocol and it s processing overhead.
<Akhil Goyal, Hemant Agrawal> Questions? <akhil.goyal@nxp.com, hemant.agrawal@nxp.com>
